Oracle 11g features van de maand: Data Guard 11g

December 2008 - Op 6 november 2007 vond de eerste officiële release plaats van de nieuwste versie van de Oracle database: 11g. In eerdere Whitebooks behandelden de specialisten van Whitehorses al diverse belangrijke nieuwe features. Deze maand: de Data Guard ‘Snapshot’ standby database & de 11g Active Data Guard option.

Data Guard is Oracle's oplossing voor high availability en disaster recovery. Het biedt een eenvoudig te configureren framework waarmee kan worden omgegaan met geplande en niet-geplande database uitval.

In een van onze vorige Whitebooks gingen al we in op het concept van "physical" en 'logical" Standby databases. Met Data Guard 11g wordt een derde type standby database geïntroduceerd, de ‘snapshot’ Standby database.

Schematisch ziet 11g Data Guard er als volgt uit:

De Snapshot Standby Database

Een Snapshot Standby database is een Physical Standby database die tijdelijk geopend kan worden voor read/write toepassingen. Op een Snapshot Standby database kan geen redo apply plaatsvinden. De Snapshot database loopt dus per definitie ‘achter’ op de Primary database.

Nadat de Snapshot database is gebruikt voor bijvoorbeeld test doeleinden kan deze weer op eenvoudige wijze naar Physical Standby geconverteerd worden en kan het synchronisatie proces met de Primary database weer gestart worden. Het switchen van Physical naar Standby database kan eindeloos herhaald worden. Bijkomend voordeel is dat een Snaphot Standby ingezet kan worden als kopie van de Primary database in een Disaster Recovery scenario.

Het switchen van Physical Standby database naar Snapshot database gaat eenvoudig. De volgende dialoog laat zien hoe een Physical Standby database geconfigureerd en geopend wordt als Snapshot Standby en weer getransformeerd wordt naar Physical Standby database. De foutboodschappen die de database laat zien in de configuratie fase wijzen ons de weg naar hoe de Snapshot geconfigureerd dient te worden. Een handleiding is bijna overbodig…

We starten met een Physical Standby database die in redo log apply mode staat:

SQL> alter database convert to snapshot standby; 
alter database convert to snapshot standby 
* 
ERROR at line 1: 
ORA-38784: Cannot create restore point 'SNAPSHOT_STANDBY_REQUIRED_12/22/2008 
18:15:31'. 
ORA-01153: an incompatible media recovery is active 

Het aanmaken van een restore point, later nodig om op terug te vallen als de Snapshot weer getransformeerd wordt in Physical Standby database, kan niet aangemaakt worden. De database staat nog in recovery mode. De recovery mode dient eerst gestopt te worden:

SQL> alter database recover managed standby database cancel; 
Database altered. 

We proberen het nog een keer:

SQL> alter database convert to snapshot standby; 
alter database convert to snapshot standby 
* 
ERROR at line 1: 
ORA-38784: Cannot create restore point 'SNAPSHOT_STANDBY_REQUIRED_12/22/2008 
18:15:56'. 
ORA-38786: Flash recovery area is not enabled. 

Op de Standby database is geen Flash Recovery area gedefinieerd. We maken de Flash Recovery area als volgt aan en proberen de database nogmaals naar Snapshot te transformeren:

SQL> alter system set db_recovery_file_dest_size=2g scope=both; 
System altered. 
SQL> alter system set db_recovery_file_dest='C:appjvaderflash_recovery_area' 
scope=both; 
System altered. 
SQL> alter database convert to snapshot standby; 
alter database convert to snapshot standby 
* 
ERROR at line 1: 
ORA-38784: Cannot create restore point 'SNAPSHOT_STANDBY_REQUIRED_12/22/2008 
18:18:26'. 
ORA-38787: Creating the first guaranteed restore point requires mount mode 
when flashback database is off.

Het aanmaken van een restore point vereist dat de database in ‘Flashback’ mode staat. Het aanzetten van de Flashback mode gaat eenvoudig: eerst wordt de database gesloten, geopend in mount mode, en Flashback wordt geactiveerd:

SQL> shutdown immediate 
Database closed. 
Database dismounted. 
ORACLE instance shut down. 
SQL> startup mount; 
ORACLE instance started. 
Total System Global Area  523108352 bytes 
Fixed Size                  1334292 bytes 
Variable Size             499123180 bytes 
Database Buffers           16777216 bytes 
Redo Buffers                5873664 bytes 

Database mounted. 
SQL> alter database flashback on; 
Database altered. 

Nu is aan alle configuratie eisen voldaan en kan de Physical Standby getransformeerd worden naar Snapshot Standby:

SQL> alter database convert to snapshot standby; 
Database altered. 
SQL> shutdown immediate 
ORA-01507: database not mounted 

ORACLE instance shut down. 
SQL> startup 

ORACLE instance started. 
Total System Global Area  523108352 bytes 
Fixed Size                  1334292 bytes 
Variable Size             499123180 bytes 
Database Buffers           16777216 bytes 
Redo Buffers                5873664 bytes 
Database mounted. 
Database opened. 
SQL> select open_mode from v$database; 

OPEN_MODE 
---------- 
READ WRITE 

Het testen kan beginnen! De Snapshot is nu read/write geopend. Bovendien kan deze op ieder gewenst moment weer omgezet worden naar Physical Standby:

SQL> shutdown immediate 
Database closed. 
Database dismounted. 
ORACLE instance shut down. 
SQL> startup mount; 
ORACLE instance started. 

Total System Global Area  523108352 bytes 
Fixed Size                  1334292 bytes 
Variable Size             499123180 bytes 
Database Buffers           16777216 bytes 
Redo Buffers                5873664 bytes 
Database mounted. 
SQL> alter database convert to physical standby; 

Database altered. 

SQL> shutdown immediate 
ORA-01507: database not mounted 

ORACLE instance shut down. 
SQL> startup 
ORACLE instance started. 

Total System Global Area  523108352 bytes 
Fixed Size                  1334292 bytes 
Variable Size             499123180 bytes 
Database Buffers           16777216 bytes 
Redo Buffers                5873664 bytes 
Database mounted. 
Database opened. 
SQL> alter database recover managed standby database using 
current logfile disconnect from session; 

Database altered. 

En we zijn weer op het punt waar we begonnen zijn, alleen hebben we ‘en passant’ de Snapshot Standby database volledig geconfigureerd!

Vanaf dit moment kan, zo vaak men maar wilt, wisselen tussen Physical en Snapshot database. Deze standby altijd bovendien altijd ingezet worden als uitwijk voor de Primary database.

11g Active Data Guard

Tot en met Oracle 10gR2 kon een Physical Standby database niet read-only geopend worden terwijl redo-apply actief was. Waarom eigenlijk niet? Is dat eigenlijk niet heel eenvoudig? Nee! Oracle staat dit niet toe en met reden!

Tot en met release 10gR2 was Oracle namelijk niet in staat de ‘read consistency’ van queries op de standby database te garanderen.

Read consistency houdt in dat, als een query wordt afgevuurd op de database, de query alleen de informatie ophaalt die aanwezig is in de database op het moment van starten van de query. De opgehaalde informatie wordt niet beïnvloed door andere transacties tijdens het uitvoeren van de query.

Hoe werkt dit intern? Op het moment dat een query afgevuurd wordt op een Primary database dan noteert Oracle het op dat moment geldende System Change Number (SCN). Het query mechanisme toetst bij het ophalen van informatie op de waarde van de in de database aanwezige SCN’s. Is de waarde kleiner of gelijk aan het ‘start SCN’ van de query dan wordt de informatie opgehaald. Is het SCN groter dan gaat de query op zoek in het Rolback Segment, nu beter bekend als UNDO segment, naar informatie zoals die was voordat er een mutatie plaatsvond die tot een hoger SCN leidde.

En zie daar het probleem waar Oracle mee geconfronteerd werd: informatie aanwezig in de Rollback Segmenten valt niet onder het Redo transport mechanisme en wordt dus NIET naar de Standby database getransporteerd.

Met de komst van 11g Active Data Guard kan de Standby database eindelijk ingezet worden voor andere bedrijfsdoelen. De database internals zijn zodanig ingrijpend gewijzigd dat read-consisteny op de aan wijzigingen onderhevige Physical Standby database gegarandeerd is!

De oplettende lezer had uit het laatste voorbeeld al af kunnen leiden dat de database read-only geopend is terwijl redo apply actief is. Twee eenvoudige queries bevestigen dit: 

SQL> select open_mode from v$database; 

OPEN_MODE 
---------- 
READ ONLY 

SQL> select recovery_mode, status from v$archive_dest_status 
2 where dest_id = 1; 

RECOVERY_MODE           STATUS 
----------------------- --------- 
MANAGED REAL TIME APPLY VALID 

Conclusie

Met de komst van 11g Active Data Guard is het Data Guard framework een wel zeer volledige oplossing geworden. De Physical Standby database kan volledig ingezet worden voor read-only toepassingen en daarmee de Primary database ontlasten.

Let wel, Data Guard maakt deel uit van de 11g Enterprise Edition en 11g Active Data Guard is hier weer een optie op. Voor Active Data Guard moet dus licentie worden afgenomen en wel voor zowel de Primary database als iedere Standby database. Deze kosten zijn echter relatief laag en, gezien de mogelijkheden die worden geboden, de investering meer dan waard!