Presentasjon lastes. Vennligst vent

Presentasjon lastes. Vennligst vent

Oracle Dataguard 11g – Praktisk bruk av standby basen, ikke bare en D/R løsning. www.keystep.nowww.keystep.no Tel 48012401 Fax 48012447 DriftsCenter 48012448.

Liknende presentasjoner


Presentasjon om: "Oracle Dataguard 11g – Praktisk bruk av standby basen, ikke bare en D/R løsning. www.keystep.nowww.keystep.no Tel 48012401 Fax 48012447 DriftsCenter 48012448."— Utskrift av presentasjonen:

1 Oracle Dataguard 11g – Praktisk bruk av standby basen, ikke bare en D/R løsning. Tel Fax DriftsCenter Nøkkelen til sikker og effektiv IT-forvaltning Ta steget

2 Hvem er jeg? •Petter Minge •Jobber som sjefskonsulent i Keystep AS •En av gründerene i Keystep AS •Ca 11 års erfaring med Oracle sine produkter. •Primær teknisk kompetanse: dba relaterte oppgaver (tuning, backup/restore osv), Dataguard, RAC, OAS(ias) osv. •Lang erfaring som teknisk prosjektleder, samt rådgivning innenfor Oracle database produkter, samt drift og overvåkning. •Erfaring fra mange forskjellige kunde miljøer (store og små) •Innleid hos Statens Vegvesen – Vegdirektoratet de siste 2 årene

3 Dataguard og primær funksjon….

4 SLA krav Trenger vår bedrift HA/DR? Konsekvensanalyse: 1) Kategoriser og lag en oversikt over hvilke systemer som er kritiske for bedriften. 2) Regn ut kosten og konsekvensen for nedetid og tap av data 3) Sett SLA verdier på de forskjellige kategoriene/systemene (f.eks A, B, C)

5 ”Standard” miljø ? •Flere baser på en server •RMAN backup som kjører hver kveld/natt inkl arkivfiler. •Ikke hyppige arkivlog backuper. •Baser i størrelses orden flere 100 GB. •Store transaksjonsmengder

6 RTO -Recovery Time Objective RPO -Recovery Point Objective A B C A, B og C er SLA verdier 1,2, || 4 1.Serverfeil (Eks: server går ned) Lav sannsynelighet 2.Media-/diskfeil Lav sannsynelighet 3.Logisk- eller brukerfeil (manipulering av data) (Eks: Batch/Rydde jobber som kjører feil, eller brukere som sletter/manipulerer data hvor det logiske datasettet blir feil) Høy sannsynelighet 4.Databasekorrupsjon (Eks: Datafiler blir korrupte.) Medium sannsynelighet 5.Databasefeil (Eks: Coredumping, heng, oracle prosesser som spinner løpsk. Redusere nedetid ved patching av en side om gangen) Lav sannsynelighet 6.Site-feil (Eks: Ett av server rommene mister strøm etc) Lav sannsynelighet Blått ”standard” miljø Timer

7 Hvordan forbedre RTO/RPO? •RAC •Dataguard •Flashback •Gridcontrol •RMAN •osv

8 Dataguard

9 • Software infrastruktur som automatisk håndterer (replikerer til) en duplikat eller standby kopi av produksjonsdatabasen (primary). • Hvis primary database blir utilgjengelig (disaster, vedlikehold, etc), kan standby databasen da bli aktivert og ta over tjenestene knyttet til databasen. • Hovedsakelig en disaster/recovery(D/R) løsning med rask tilgjengelighet, med minimalt eller inget tap av data. • Opprettes enten som en kald kopi eller rman kloning fra primary (engangs hendelse) •Alle endringer i primary blir da overført til standby •Kan ha opptil 9 standby databaser (30 i 11gr2)

10 Logical Standby •Logical standby database: •Synkroniseres med primary ved å omgjøre redo data fra primary til SQL statements som blir kjørt. •Inneholder samme logiske informasjon (rader) som primary •Er en åpen, selvstendig og aktiv database. •Kan kjøres spørringer mot selv om den mottar endrede data fra primary. •Kan legge inn ekstra indexer og materialiserte views for bedre ytelse. •Ikke alle data typer er supportert. Primary Database Logical Standby Database Redo block data Network Åpen for rapport spørringer (les) Omgjør Redo til SQL

11 Physical standby •Physical standby database: •Er en block-for-block kopi av primary database. •Bruker database recovery funksjonalitet til å legge til endrede data. •Må stå i recovery modus for å motta endrede data. •Den beste løsningen for D/R. Primary Database Physical Standby Database Redo block data Network Block-for-block recovery Managed recovery modus

12 Fakta •Enterprise Edition •Alle dataguard siter (primary og standby) må kjøres på samme Oracle image som er bygd for den samme platformen (* note ) •Kan ha ulik antall cpu og minne. •Primary database må kjøre ARCHIVELOG mode. •Data blir overført via ”sqlnet” •Gratis med enterprise edition, men…

13 Physical Standby database

14 Protection Modes •Maximum Protection •Maximum Availability •Maximum Performance

15 Protection Modes – Protection •Maximum protection •Høyeste grad av beskyttelse •Ingen datatap, da transaksjonen ikke vil fortsette før den får bekreftet at den er lagret i standby databasen. •Primary database vil bli tatt ned hvis ingen kontakt med standby database. •Passer best til systemer hvor inget tap av data er akseptabelt. •Ytelsen kan/vil få konsekvenser. Network Block-for-block recovery Physical Standby Database Primary Database Får kontakt med standby? Commit OK? Transaksjon Ja Nei Ja Nei Primary går ned Transaksjonen venter på bekreftet commit OK i standby. Kan fortsette videre hvis OK.

16 Protection Modes - Availability •Maximum availability •Ingen datatap, da transaksjonen ikke vil fortsette før den får bekreftet at den er lagret i standby databasen. •MEN, hvis standby database ikke er tilgjengelig, vil den gå over til "Maximum performance" slik at transaksjonen går igjennom. •Denne løsningen passer best hvor tilgjengelighet er viktig, itillegg til inget tap av data. •MEN, man kan tape data hvis standby database har vært utilgjengelig og uheller i primary skulle da slå til. •Ytelsen kan/vil få konsekvenser. Network Block-for-block recovery Physical Standby Database Primary Database Får kontakt med standby? Commit OK? Transaksjon Ja Nei Ja Nei DG går over til maximum performance Transaksjonen venter på bekreftet commit OK i standby. Kan fortsette videre hvis ikke OK. DG går over til maximum performance

17 Protection Modes - Performance •Maximum performance •Minimal eller ingen tap av data. •Minimal eller ingen ytelses påvirkning •Passer for de systemer hvor tilgjengelighet og ytelse er viktig, og noe (minimalt) tap av data er akseptabelt. Network Block-for-block recovery Physical Standby Database Primary Database Får kontakt med standby? Commit OK? Transaksjon Ja Nei Ja Nei Primary fortsetter som normalt. Transaksjonen venter ikke på bekreftet commit OK i standby. Standby henter seg inn igjen automatisk når den er tilgjengelig igjen. Primary fortsetter som normalt.

18 Redo transmission physical standby Maximum performance (to typer overføring: arch og lgwr) ARC Primary database transaksjoner Online redo logs FAL LGWR Archived redo logs ARC Standby redo logs Archived redo logs Oracle net LNS RFS MRP 10gr2/11g 9i / 10gr1 Physical Standby LGWR redo transmission Dataguard broker (optional) Async buffer

19 Switchover/Failover •Switchover •Er en kontrollert og planlagt ombytting av rollene. Primary blir standby og standby blir primary. •Inget tap av data •Kan fint gjøres frem og tilbake, og dataguard løsningen blir inntakt. •Failover •En failover må kjøres hvis primary database eller server ikke lenger er tilgjengelig. •Standby databasen tar over rollen som primary. •Den orginale primary databasen er ikke lenger med i dataguard konfigurasjonen. •Den nye primary databasen prøver å få tak i så mye data som mulig fra den orginale primary databasen, mulig man må kutte strengen. •Man kan miste noe data.

20 Flashback

21 Hva er Flashback? Flashback er en måte å ”restore” seg bakover på, istedenfor den tradisjonelle måten som er fremover ved f.eks bruker feil (sletter for mye data i en tabell osv) Tidslinje RMAN backup Tradisjonel restore Feil oppstått! Oppdager feilen! Alternativene man har for å hente tilbake dataene slettet fra en tabell, er i utgangspunktet å kjøre en full restore med siste backup (Punkt 3) frem til Punkt 2. Data mellom Punkt 1 og 2 kan gå tapt, og evt mellom 2 og 3 kan gå tapt. Et annet alternativ er å klone prod database, og kjøre export/import til den tabellen man har slettet for mye data fra. Dette kan ta veldig lang tid.

22 Flashback Tidslinje RMAN backup Flashback Feil oppstått! 2 1 Oppdager feilen! 3 Ved bruk av flashback kan man spoole seg bakover frem til like før feilen oppstod enten på objekter (tabeller osv) eller hele databasen. Med dette vil man kunne spare mye tid! For å kunne ta i bruk flashback må dette settes på i databasen. Det vil da bli opprettet i tilegg til ordinære arkivfiler, en del andre filer som skal brukes til flashback hvis det er behov. Tips: Sett flashback=on på standby databasene

23 Fordeler med Flashback på standby •Slipper å tenke på å sette på delay mellom primary og standby •Teste script mot oppdaterte data •Ta en kald kopi for oppfriskning av utv eller test miljø uten nedetid på primary •Flere restore muligheter: •Skjemaer •Base •Objekter NB! Husk å sette DB_FLASHBACK_RETENTION_TARGET til ”riktig” verdi, og størrelse på flashback området

24 Hvordan påvirker Dataguard og Flashback SLA kravene?

25 RTO RPO A B C A, B og C er SLA klasser 1,2, || 4 1,2, || 4 1.Serverfeil (Eks: server går ned) Lav sannsynelighet 2.Media-/diskfeil Lav sannsynelighet 3.Logisk- eller brukerfeil (manipulering av data) (Eks: Batch/Rydde jobber som kjører feil, eller brukere som sletter/manipulerer data hvor det logiske datasettet blir feil) Høy sannsynelighet 4.Databasekorrupsjon (Eks: Datafiler blir korrupte.) Medium sannsynelighet 5.Databasefeil (Eks: Coredumping, heng, oracle prosesser som spinner løpsk. Redusere nedetid ved patching av en side om gangen) Lav sannsynelighet 6.Site-feil (Eks: Ett av server rommene mister strøm etc) Lav sannsynelighet Blått gammelt miljø Dataguard og flashback Timer

26 ROI – Return of investment

27 Avlastning RMAN Physical Standby Database Primary Database Redo block data MRP Denne står konstant i MRP for D/R RMAN backup Hvis det er en 24/7 database, med masse transaksjoner døgnet rundt, som er avhengig av best mulig ytelse, kan man kjøre RMAN backup mot standby databasen for å avlaste Primary database.

28 Vedlikehold Physical Standby Database Primary Database Redo log shipping Primary Database Physical Standby Database Switchover OK Primary Database Physical Standby Database Henter seg inn igjen når standby base er tilgjengelig Physical Standby Database Primary Database Redo log shipping Switchover OK Ingen tap av data, men brukere vil få en liten nedetid i det man kjører en switchover. Kan her da utføre server vedlikehold etc, mens tjenestene likevel er tilgjengelig.

29 Active Dataguard

30 Read Only modus < 11g Physical standby db i READ-ONLY modus, og det kan da kjøres rapporter mot på historiske data. Physical Standby Database 1 Primary Database Physical Standby Database 2 Redo block data MRP Denne står konstant i MRP for D/R READ-ONLY Standby base nr 2, er i MRP på natten for å synkronisere seg opp mot Primary. På dagtid blir MRP avbrutt, og standby basen går opp i READ-ONLY modus slik at brukere kan kjøre større rapporter på historiske data (fra natten og eldre).

31 Active dataguard11g Physical Standby Database 1 Primary Database Physical Standby Database 2 Redo block data MRP Denne står konstant i MRP for D/R READ-ONLY 11G Activ Dataguard – Read Only modus på real time data Med active dataguard bør man bruke realtime apply: SQL> recover managed standby database using current logfile disconnect;

32 Tips rundt active dataguard •Legge på indexer til bruk for spørringer •Alter index med visible eller invisible. •Evt sjongler med ” alter session set optimizer_use_invisible_indexes= ; •NB! Husk at de blir oppdatert ved dml operasjoner. •Behov for skrive operasjoner i read only database •Lag en db link i primary som peker på primary, den blir flyttet over til standby. •Du kan nå skrive til denne linken fra standby basen. Datene blir flyttet over til primary, som igjen kommer tilbake til standby. •NB! Store skriveoperasjoner bør ikke gjøres i denne basen. Active Standby Database Primary Database Redo block data MRP

33 Snapshot standby database og read/write med flashback

34 MRP 1) Standby – READ-WRITE (10g (også 11g)) Vi skal i dette eksemplet se hvordan man kan bruke physical standby databasen til å teste f.eks dml operasjoner, eller migreringsjobber som man er usikker på om kjøres ok eller ikke. Istedenfor å kjøre dette i test miljø kan man bruke en standby database. Physical Standby Database 1 Primary Database Physical Standby Database 2 Redo block data MRP Denne står konstant i MRP for D/R SQL> ALTER SYSTEM SET DB_RECOVERY_FILE_DEST_SIZE=20G; SQL> ALTER SYSTEM SET DB_RECOVERY_FILE_DEST='/arch/oradata'; READ-WRITE SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; SQL> CREATE RESTORE POINT GUARANTEE 2 FLASHBACK DATABASE; SQL> ALTER SYSTEM ARCHIVE LOG CURRENT; SQL> ALTER SYSTEM SET 2 LOG_ARCHIVE_DEST_STATE_3=DEFER; SQL> ALTER DATABASE ACTIVATE STANDBY DATABASE; SQL> STARTUP MOUNT FORCE; SQL> ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE 2 PERFORMANCE; SQL> ALTER DATABASE OPEN; 5 6 Physical standby database har nå blitt en stand-alone read-write database som man kan teste dml statement osv mot. Stand alone Database Konvertert til Stand-alone db

35 Stand alone Database 2) Standby –READ-WRITE MRP Physical Standby Database 1 Primary Database Physical Standby Database 2 Redo block data MRP Denne står konstant i MRP for D/R SQL> SHUTDOWN IMMEDIATE; SQL> STARTUP MOUNT FORCE; SQL> FLASHBACK DATABASE TO RESTORE POINT ; SQL> ALTER DATABASE CONVERT TO PHYSICAL STANDBY; SQL> STARTUP MOUNT FORCE; READ-WRITE SQL> ALTER SYSTEM SET 2 LOG_ARCHIVE_DEST_STATE_3=ENABLE; SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE 2 DISCONNECT; Stand-alone db har nå blitt rullet tilbake slik at den kan brukes som en Physical standby database igjen. Konvertert tilbake til Standby db

36 MRP Snapshot standby database (11g) Physical Standby Database 1 Primary Database Physical Standby Database 2 Redo block data MRP Denne står konstant i MRP for D/R SQL> alter database convert to snapshot standby; -- Basen blir dismounted så må startes READ-WRITE 1 Stand alone Database Konvertert til Stand-alone db Snapshot standby MRP Physical Standby Database 1 Primary Database Physical Standby Database 2 Redo block data MRP Denne står konstant i MRP for D/R SQL> alter database convert to physical standby; -- Basen blir dismounted så må startes 2 Physical standby

37 Eksempel på restore •Hvis feil i ett skjema eller objekt, må hele basen restores uten flashback. •Med flashback kan man relativt raskt bygge opp ett skjema eller objekt med data fra tidligere tidspunkt. •F.eks Flash tilbake standby base før feilen oppstod •Åpne basen i read-write modus, og: •Evt lag en database link mellom primary og standby, overfør data som er slettet. •Evt ta en export av skjema og importer i primary •Flash tilbake standby til å bli en standby database igjen.

38 Flashback og read/write restore eksempel Tidslinje RMAN backup Standby db Feil oppstått! 2 1 Oppdager feilen primary! 4 Åpner standby db i read/write 3 Flasher standby db tilbake til før feil Kan nå da: -Exportere skjema, objekter etc, og importer til primary -Lage db link og bygge opp ”ødelagte” data på nytt -Osv…. 5 Flasher standby db tilbake til punkt 3, og starter MRP. Primary overfører da endringene over til standby. Primary har nå blitt fikset, og de endringene der blir nå da overført til standby som igjen er en tro kopi av primary. 6

39 Snapshot standby og flashback •Åpner seg en del nye restore muligheter •Update-to-date data for test formål •RAT •Tuning •Dml script osv •Kalde kopier/kloninger •Backup

40 Refreshing av utv/test/qa baser

41 Tradisjonel rman kloning (<11g) TEST Database Primary Database RMAN backup (til disk eller tape) RMAN Database Tradisjonel kloning: Backup primary(prod) run { allocate auxiliary channel dev1 type 'SBT_TAPE'; backup database plus archivelog; } Connect target, catalog og auxilliary (hvis backup til disk må backup-piecene flyttes over til TEST server) scp Kjør rman duplicate: run { allocate auxiliary channel dev1 type 'SBT_TAPE'; duplicate target database to TEST; } 3 2 1

42 Active rman kloning (11g) TEST Database Primary Database RMAN backup (til disk eller tape) RMAN Database Active rman kloning: Connect target og auxilliary Kjør rman active duplicate: run { duplicate target database to TEST from active database; } Filene blir flyttet over sqlnet. Slipper å kjøre backup først, og man henter da filene rett fra PROD db. ( Evt for å opprette standby db: run { duplicate target database for standby from active database; } ) 1 2

43 MRP RMAN active duplicate – standby db Physical Standby Database 1 Primary Database Physical Standby Database 2 Redo block data MRP Denne står konstant i MRP for D/R SQL> alter database convert to snapshot standby; READ-WRITE 1 Stand alone Database Konvertert til Stand-alone db Active rman kloning fra snapshot standby: 1) Connect target (som her er ”standby db” ) og auxilliary 2) Kjør rman active duplicate: run { duplicate target database to TEST from active database; } Her blir ikke PROD primary db berørt i det hele tatt. Test Database SQL> alter database convert to physical standby; --(Kjøres for å få snapshot standby basen tilbake som en standby db, TEST basen blir ikke rørt her) 2

44 MRP RMAN active duplicate – tilbake i tid Physical Standby Database 1 Primary Database Physical Standby Database 2 Redo block data MRP Denne står konstant i MRP for D/R SQL> ALTER SYSTEM SET DB_RECOVERY_FILE_DEST_SIZE=20G; SQL> ALTER SYSTEM SET DB_RECOVERY_FILE_DEST='/arch/oradata'; READ-WRITE SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; SQL> CREATE RESTORE POINT GUARANTEE 2 FLASHBACK DATABASE; SQL> FLASHBACK DATABASE TO TIMESTAMP to_timestamp(' :00:00‘,‘YYYY-MM-DD HH24:MI:SS’); 1 2 SQL> ALTER DATABASE ACTIVATE STANDBY DATABASE; SQL> ALTER DATABASE OPEN; 3 4 Physical standby database har nå blitt en stand-alone read-write database som inneholder ”fortids-data” som man kan kjøre ”rman active duplicate” på. Stand alone Database Konvertert til Stand-alone db Test Database Connect og “duplicate target database to TEST from active database;” 5 6 Konverter read-write db tilbake til physcal standby

45 Rolling upgrades Physical Standby Database Primary Database Redo log shipping 1 a)Kreere garantert restore punkt b)Logminer build Logical Standby Database Primary Database Redo log shipping 2 a)Konverter physical til logical standby med keep identity b)Oppgrader standby basen c)Test og se at alt er OK Primary Database Logical Standby Database Switchover 4 a)Flashback standby til garantert restore punkt b)Mount standby basen i ny OH (patchet) Primary Database Physical Standby Database Redo log shipping 5 a)Konverter logical standby til physical b)Start managed recovery processen Physical Standby Database Primary Database Switchover Redo log shipping server01server Forberedelser på begge noder 7 Rydde opp på begge noder (Her ved switchover vil det bli liten nedetid)

46 0 - stop evt broker - disable faststart failover - lag evt standby redo log på begge sider - Dataguard må kjøres i max performace eller availability - installer oppgradert ORACLE_HOME på begge noder paralellt - IKKE endre compatible parameter under prosessen - sjekk om usupportere objekter er i bruk i basen SELECT DISTINCT OWNER, TABLE_NAME FROM DBA_LOGSTDBY_UNSUPPORTED; SELECT OWNER, TABLE_NAME FROM DBA_LOGSTDBY_NOT_UNIQUE WHERE (OWNER, TABLE_NAME) NOT IN (SELECT DISTINCT OWNER, TABLE_NAME FROM DBA_LOGSTDBY_UNSUPPORTED) AND BAD_COLUMN = 'Y'; 1 primary (server01): SQL> CREATE RESTORE POINT preupgrade GUARANTEE FLASHBACK DATABASE; --standby (server02) (opsjonal) --(sikkerhet ved evt feil) --ALTER DATABASE RECOVER MANAGED STANDBY DATABASE cancel; --CREATE RESTORE POINT nullpunktstandby GUARANTEE FLASHBACK DATABASE; --ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION; standby (server02): SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; primary (server01): SQL> EXECUTE DBMS_LOGSTDBY.BUILD; Rolling upgrade - kommandoer

47 2 standby (server02): SQL> SHUTDOWN IMMEDIATE SQL> STARTUP MOUNT SQL> ALTER DATABASE RECOVER TO LOGICAL STANDBY KEEP IDENTITY; (kan ta litt tid denne) SQL> ALTER DATABASE OPEN; Logg inn i ny sessjon på standby db og vent på denne query til du får IDLE: SQL> SELECT SESSION_ID, STATE FROM V$LOGSTDBY_STATE; SESSION_ID STATE LOADING DICTIONARY SQL> r 1* SELECT SESSION_ID, STATE FROM V$LOGSTDBY_STATE SESSION_ID STATE APPLYING SQL> r 1* SELECT SESSION_ID, STATE FROM V$LOGSTDBY_STATE SESSION_ID STATE IDLE primary (server01): SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=DEFER SCOPE=MEMORY; standby (server02) som nå er logical standby SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY; SQL> CREATE RESTORE POINT bckupgrade GUARANTEE FLASHBACK DATABASE; SQL> SHUTDOWN IMMEDIATE --- startup upgrade,Upgrade oracle, catupgrd.sql osv.... SQL> SHUTDOWN IMMEDIATE primary (server01): SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE SCOPE=MEMORY; standby (server02) som nå er logical standby: SQL> STARTUP SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;

48 3 Switchover (liten nedetid for brukere) primary (server01): SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE; SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO LOGICAL STANDBY; standby (server02) som nå er logical standby: Vent på denne query til den returnerer "TO_PRIMARY" SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE; SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO LOGICAL PRIMARY; ny primary (server02): SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=DEFER SCOPE=MEMORY; 4 ny standby (server01): SQL> SHUTDOWN IMMEDIATE; SQL> STARTUP MOUNT; SQL> FLASHBACK DATABASE TO RESTORE POINT preupgrade; SQL> SHUTDOWN IMMEDIATE; -- Start opp base i ny ORACLE_HOME SQL> STARTUP MOUNT; 5 ny standby (server01): SQL> ALTER DATABASE CONVERT TO PHYSICAL STANDBY; SQL> SHUTDOWN IMMEDIATE SQL> STARTUP MOUNT; SQL> RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT; ny primary (server02): SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE;

49 6 Switchover tilbake (liten nedetid for brukere): ny primary (server02): Vent på denne query til den returnerer "TO STANDBY" : SQL> r 1* SELECT SWITCHOVER_STATUS FROM V$DATABASE; SWITCHOVER_STATUS RESOLVABLE GAP SQL> r 1* SELECT SWITCHOVER_STATUS FROM V$DATABASE; SWITCHOVER_STATUS LOG SWITCH GAP SQL> r 1* SELECT SWITCHOVER_STATUS FROM V$DATABASE; SWITCHOVER_STATUS TO STANDBY ny primary (server02): -- blir nå satt tilbake til standby igjen SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO STANDBY WITH SESSION SHUTDOWN; ny standby (server01): Vent på denne query til den returnerer "TO PRIMARY": SQL> r 1* SELECT SWITCHOVER_STATUS FROM V$DATABASE; SWITCHOVER_STATUS NOT ALLOWED SQL> r 1* SELECT SWITCHOVER_STATUS FROM V$DATABASE; SWITCHOVER_STATUS SWITCHOVER PENDING SQL> r 1* SELECT SWITCHOVER_STATUS FROM V$DATABASE; SWITCHOVER_STATUS TO PRIMARY SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY; --har nå blitt orginal primary igjen primary (server01): SQL> ALTER DATABASE OPEN; standby (server02): SQL> SHUTDOWN IMMEDIATE; SQL> STARTUP MOUNT; SQL> RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT; -- Sjekk alert log osv på begge noder

50 Rolling upgrades 7 -drop restore punkt i begge baser -fjern evt gamle oracle_home -Evt annet

51 Oppsummering •DR løsning for de aller fleste scenarior •RMAN avlastning primary •Real time query - avlastning primary •”Up-to-date” read/write db for test formål •Enklere klone muligheter •Flere restore muligheter •Rolling upgrades (minimal nedetid)

52 Spørsmål?


Laste ned ppt "Oracle Dataguard 11g – Praktisk bruk av standby basen, ikke bare en D/R løsning. www.keystep.nowww.keystep.no Tel 48012401 Fax 48012447 DriftsCenter 48012448."

Liknende presentasjoner


Annonser fra Google