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

Hvem er jeg? Petter.Minge@keystep.no 48012404 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 Petter.Minge@keystep.no 48012404

Dataguard og primær funksjon….

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)

”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

5 C RPO-Recovery Point Objective 8 1,2,6 2 || 4 4 1 B 3 4 A 1 4 8 Serverfeil (Eks: server går ned) Lav sannsynelighet Media-/diskfeil Lav sannsynelighet 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 Databasekorrupsjon (Eks: Datafiler blir korrupte.) Medium sannsynelighet Databasefeil (Eks: Coredumping, heng, oracle prosesser som spinner løpsk. Redusere nedetid ved patching av en side om gangen) Lav sannsynelighet Site-feil (Eks: Ett av server rommene mister strøm etc) Lav sannsynelighet Timer C 5 RPO-Recovery Point Objective 8 1,2,6 2 || 4 4 1 B 3 4 A Timer 1 4 8 RTO-Recovery Time Objective A, B og C er SLA verdier Blått ”standard” miljø

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

Dataguard

Dataguard 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)

Åpen for rapport spørringer (les) 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 Omgjør Redo til SQL Åpen for rapport spørringer (les)

Managed recovery modus 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 Block-for-block recovery Network Managed recovery modus

Fakta Enterprise Edition Alle dataguard siter (primary og standby) må kjøres på samme Oracle image som er bygd for den samme platformen (* note 413484.1) 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…

Physical Standby database

Protection Modes Maximum Protection Maximum Availability Maximum Performance

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. Physical Standby Database Primary Database Får kontakt med standby? Commit OK? Network Ja Block-for-block recovery Ja Nei Nei Primary går ned Primary går ned Transaksjon Transaksjonen venter på bekreftet commit OK i standby. Kan fortsette videre hvis OK.

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. Physical Standby Database Primary Database Får kontakt med standby? Commit OK? Network Ja Block-for-block recovery Ja Nei Nei DG går over til maximum performance DG går over til maximum performance Transaksjon Transaksjonen venter på bekreftet commit OK i standby. Kan fortsette videre hvis ikke OK.

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. Physical Standby Database Primary Database Får kontakt med standby? Commit OK? Network Ja Block-for-block recovery Ja Nei Nei Primary fortsetter som normalt. Primary fortsetter som normalt. Transaksjon Transaksjonen venter ikke på bekreftet commit OK i standby. Standby henter seg inn igjen automatisk når den er tilgjengelig igjen.

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

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.

Flashback

Hva er Flashback? Tradisjonel restore 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) Tradisjonel restore 1 2 Tidslinje 3 Oppdager feilen! Feil oppstått! RMAN backup 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.

Flashback Tips: Sett flashback=on på standby databasene Flashback 1 2 Tidslinje Oppdager feilen! Feil oppstått! RMAN backup 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! SELECT ESTIMATED_FLASHBACK_SIZE FROM V$FLASHBACK_DATABASE_LOG; SELECT OLDEST_FLASHBACK_SCN, OLDEST_FLASHBACK_TIME FROM V$FLASHBACK_DATABASE_LOG; SELECT CURRENT_SCN FROM V$DATABASE; 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

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

Hvordan påvirker Dataguard og Flashback SLA kravene?

Serverfeil (Eks: server går ned) Lav sannsynelighet Media-/diskfeil Lav sannsynelighet 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 Databasekorrupsjon (Eks: Datafiler blir korrupte.) Medium sannsynelighet Databasefeil (Eks: Coredumping, heng, oracle prosesser som spinner løpsk. Redusere nedetid ved patching av en side om gangen) Lav sannsynelighet Site-feil (Eks: Ett av server rommene mister strøm etc) Lav sannsynelighet Timer C 5 8 1,2,6 RPO 2 || 4 4 1 B 3 4 4 1,2,6 3 A 5 2 || 4 Timer Blått gammelt miljø Dataguard og flashback 1 4 8 RTO A, B og C er SLA klasser

ROI – Return of investment

Avlastning RMAN Physical Standby Database Primary Database 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. Physical Standby Database Primary Database Redo block data Denne står konstant i MRP for D/R MRP RMAN backup RMAN backup

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

Active Dataguard

Read Only modus < 11g Physical Standby Database 1 Primary Database Physical standby db i READ-ONLY modus, og det kan da kjøres rapporter mot på historiske data. Physical Standby Database 1 Denne står konstant i MRP for D/R MRP Primary Database Redo block data Physical Standby Database 2 MRP 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). READ-ONLY

Active dataguard11g Physical Standby Database 1 Primary Database 11G Activ Dataguard – Read Only modus på real time data Physical Standby Database 1 Denne står konstant i MRP for D/R MRP Primary Database Redo block data Physical Standby Database 2 I utgangspunktet så er ikke awr verktøy supportert mot active dataguard. Se note 454848.1 for bruk av statspack. MRP READ-ONLY Med active dataguard bør man bruke realtime apply: SQL> recover managed standby database using current logfile disconnect;

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=<true eller false>; 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

Snapshot standby database og read/write med flashback

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 Redo block data MRP Primary Database Denne står konstant i MRP for D/R Physical Standby Database 2 Stand alone Database MRP Konvertert til Stand-alone db READ-WRITE 2 SQL> ALTER SYSTEM ARCHIVE LOG CURRENT; 1 SQL> ALTER SYSTEM SET DB_RECOVERY_FILE_DEST_SIZE=20G; SQL> ALTER SYSTEM SET DB_RECOVERY_FILE_DEST='/arch/oradata'; 4 SQL> ALTER SYSTEM SET 2 LOG_ARCHIVE_DEST_STATE_3=DEFER; 3 SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; SQL> CREATE RESTORE POINT <Tilbake_til_standby> GUARANTEE 2 FLASHBACK DATABASE; 5 SQL> ALTER DATABASE ACTIVATE STANDBY DATABASE; 6 SQL> STARTUP MOUNT FORCE; SQL> ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE 2 PERFORMANCE; SQL> ALTER DATABASE OPEN; Physical standby database har nå blitt en stand-alone read-write database som man kan teste dml statement osv mot.

2) Standby –READ-WRITE Physical Standby Database 1 Redo block data MRP Primary Database Denne står konstant i MRP for D/R Physical Standby Database 2 Stand alone Database MRP Konvertert tilbake til Standby db READ-WRITE 3 SQL> ALTER SYSTEM SET 2 LOG_ARCHIVE_DEST_STATE_3=ENABLE; 1 SQL> SHUTDOWN IMMEDIATE; SQL> STARTUP MOUNT FORCE; SQL> FLASHBACK DATABASE TO RESTORE POINT <Tilbake_til_standby>; SQL> ALTER DATABASE CONVERT TO PHYSICAL STANDBY; 2 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.

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

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.

Flashback og read/write restore eksempel Standby db Flasher standby db tilbake til før feil 3 1 2 Tidslinje Oppdager feilen primary! Feil oppstått! 4 RMAN backup Åpner standby db i read/write 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. 6 Primary har nå blitt fikset, og de endringene der blir nå da overført til standby som igjen er en tro kopi av primary.

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

Refreshing av utv/test/qa baser

Tradisjonel rman kloning (<11g) 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 <packpiece’s> <testserver> Kjør rman duplicate: run duplicate target database to TEST; 1 TEST Database Primary Database 2 RMAN backup (til disk eller tape) RMAN Database 3

Active rman kloning (11g) 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; ) TEST Database Primary Database 1 2 RMAN backup (til disk eller tape) RMAN Database

RMAN active duplicate – standby db Physical Standby Database 1 Redo block data MRP Primary Database Denne står konstant i MRP for D/R Physical Standby Database 2 Stand alone Database MRP Konvertert til Stand-alone db READ-WRITE 1 SQL> alter database convert to snapshot standby; 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 2 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)

RMAN active duplicate – tilbake i tid Physical Standby Database 1 Redo block data MRP Primary Database Denne står konstant i MRP for D/R Physical Standby Database 2 Stand alone Database MRP Konvertert til Stand-alone db READ-WRITE 1 SQL> ALTER SYSTEM SET DB_RECOVERY_FILE_DEST_SIZE=20G; SQL> ALTER SYSTEM SET DB_RECOVERY_FILE_DEST='/arch/oradata'; 2 SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; SQL> CREATE RESTORE POINT <Tilbake_til_standby> GUARANTEE 2 FLASHBACK DATABASE; SQL> FLASHBACK DATABASE TO TIMESTAMP to_timestamp('2010-02-15 14:00:00‘,‘YYYY-MM-DD HH24:MI:SS’); 5 Connect og “duplicate target database to TEST from active database;” 3 SQL> ALTER DATABASE ACTIVATE STANDBY DATABASE; 4 SQL> ALTER DATABASE OPEN; Test Database 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å. 6 Konverter read-write db tilbake til physcal standby

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

Rolling upgrade - kommandoer - 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; SQL> EXECUTE DBMS_LOGSTDBY.BUILD;

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 ---------- ---------------------------------------------------------------- 1 LOADING DICTIONARY SQL> r 1* SELECT SESSION_ID, STATE FROM V$LOGSTDBY_STATE 1 APPLYING 1 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; --- startup upgrade,Upgrade oracle, catupgrd.sql osv.... 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;

3 4 5 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> 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; -- Start opp base i ny ORACLE_HOME 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;

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 LOG SWITCH GAP TO STANDBY -- 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": NOT ALLOWED SWITCHOVER PENDING 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

7 drop restore punkt i begge baser fjern evt gamle oracle_home Evt annet Rolling upgrades http://www.oracle.com/technology/deploy/availability/pdf/maa_wp_11g_transientlogicalrollingupgrade.pdf

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)

Spørsmål?