Drastisch versnellen van Oracle database recovery met incremental updated backups

Bij een calamiteit is het meestal gewenst om zo snel mogelijk weer up & running te zijn.

Het is dan best mogelijk dat een restore- en recoverproces erg lang gaat duren. Deze tijd kan drastisch ingekort worden door met RMAN gebruik te maken van zogenaamde incremental updated backups. In dit scenario wordt gebruik gemaakt van image copies die tijdens het maken van een incremental backup bijgewerkt worden met deze incremental backup.

Voordat we de incremental updated backup strategie gaan bespreken, behandelen we de gebruikte termen. Een image copy is een door RMAN gemaakte 1:1 kopie van een datafile. Bij een eventuele restore hoeft de datafile dus niet opnieuw samengesteld te worden uit de backuppiece. Een backuppiece is een door RMAN gemaakt binair backupbestand.

Een incremental backup is een backup waarin de gewijzigde blokken sinds de laatste incremental backup zijn opgenomen. We onderscheiden hierbij 2 levels: een level 0 waarin alle blokken zitten die ooit zijn gewijzigd in een datafile. In een level 1 backup worden alleen de gewijzigde blokken opgenomen sinds de vorige level 0 of 1. Een incremental backup kan alleen gemaakt worden van datafiles en dus niet van controlfile, spfile en archived redologfiles.

Bij de incremental updated backup strategie worden image copies bijgewerkt aan de hand van de incremental backup die we op dat moment maken. Dit kan op de volgende manier:

RMAN> run {
2  recover copy of database with tag ′incremental_updated_bu′;
3  backup incremental level 1
4    for recover of copy with tag ′incremental_updated_bu′
5    database; }

De opgegeven TAG moet zowel bij het recover als de backup commando gelijk zijn.

We gebruiken in dit voorbeeld een database waarvan de totale grootte van de datafiles 1,5gb is. Tussentijds hebben we wijzigingen uitgevoerd.

Als we bovenstaand RUN-blok voor de eerste keer uitvoeren hebben we nog geen image copies en incremental backups. RMAN geeft dan onderstaande melding:

Starting recover at 28 Feb 2011 15:10:46
using channel ORA_DISK_1
no copy of datafile 1 found to recover
no copy of datafile 2 found to recover
no copy of datafile 3 found to recover
no copy of datafile 4 found to recover
no copy of datafile 5 found to recover
no copy of datafile 6 found to recover
no copy of datafile 7 found to recover
Finished recover at 28 Feb 2011 15:10:46

Starting backup at 28 Feb 2011 15:10:46
using channel ORA_DISK_1
no parent backup or copy of datafile 3 found
no parent backup or copy of datafile 2 found
no parent backup or copy of datafile 1 found
no parent backup or copy of datafile 5 found
no parent backup or copy of datafile 7 found
no parent backup or copy of datafile 4 found
no parent backup or copy of datafile 6 found

Vervolgens wordt er voor elke datafile een image copy gemaakt:

channel ORA_DISK_1: starting datafile copy
input datafile file number=00003 name=/opt/app/oracle/oradata/ora11g/undotbs01.dbf
output file name=/opt/app/oracle/recovery/ORA11G/datafile/o1_mf_undotbs1_6pqc76z6_.dbf tag=INCREMENTAL_UPDATED_BU RECID=8 STAMP=744304265
(…)
channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:01

Tevens wordt er een incremental backup van de controlfile en de spfile gemaakt. Dit is natuurlijk geen echte incremental backup, omdat dit niet kan van de controlfile en de spfile:

channel ORA_DISK_1: starting incremental level 1 datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
including current control file in backup set
including current SPFILE in backup set
(…)

Het uitvoeren van bovenstaand RUN-blok duurde 1 minuut en 13 seconden.

Vervolgens bekijken we welke backups we inmiddels hebben:

RMAN> list backup summary;

List of Backups
===============
Key     TY LV S Device Type Completion Time      #Pieces #Copies Compressed Tag
------- -- -- - ----------- -------------------- ------- ------- ---------- ---
36      B  F  A DISK        28 May 2010 16:28:03 1       1       NO         FULL CONSISTENT BACKUP
37      B  F  A DISK        28 May 2010 16:28:05 1       1       NO         FULL CONSISTENT BACKUP
38      B  F  A DISK        28 May 2010 16:28:07 1       1       NO         1E TOOLS BACKUP
39      B  F  A DISK        28 May 2010 16:28:09 1       1       NO         2E TOOLS BACKUP
40      B  F  A DISK        28 May 2010 16:28:11 1       1       NO         3E TOOLS BACKUP
41      B  1  A DISK        28 Feb 2011 15:11:57 1       1       NO         INCREMENTAL_UPDATED_BU

Met onderstaand commando bekijken we welke image copies er zijn:

RMAN> list copy of database;

List of Datafile Copies
=======================
Key     File S Completion Time      Ckp SCN    Ckp Time
------- ---- - -------------------- ---------- --------------------
10      1    A 28 Feb 2011 15:11:47 83692649   28 Feb 2011 15:11:37
Name: /opt/app/oracle/recovery/ORA11G/datafile/o1_mf_system_6pqc8s85_.dbf
Tag: INCREMENTAL_UPDATED_BU
(…)
12      7    A 28 Feb 2011 15:11:54 83692656   28 Feb 2011 15:11:53
Name: /opt/app/oracle/recovery/ORA11G/datafile/o1_mf_tools_6pqc99h7_.dbf
Tag: INCREMENTAL_UPDATED_BU

Bij het voor de tweede keer uitvoeren van het RUN-blok zijn er al wel image copies, maar is er nog geen incremental backup van de datafiles aanwezig. RMAN zal dan ook alleen een incremental backup gaan maken:

Starting recover at 28 Feb 2011 15:12:48
using channel ORA_DISK_1
no copy of datafile 1 found to recover
no copy of datafile 2 found to recover
no copy of datafile 3 found to recover
no copy of datafile 4 found to recover
no copy of datafile 5 found to recover
no copy of datafile 6 found to recover
no copy of datafile 7 found to recover
Finished recover at 28 Feb 2011 15:12:48

Starting backup at 28 Feb 2011 15:12:48
using channel ORA_DISK_1
channel ORA_DISK_1: starting incremental level 1 datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
input datafile file number=00003 name=/opt/app/oracle/oradata/ora11g/undotbs01.dbf
input datafile file number=00002 name=/opt/app/oracle/oradata/ora11g/sysaux01.dbf
(…)
piece handle=/opt/app/oracle/recovery/ORA11G/backupset/2011_02_28/o1_mf_nnnd1_INCREMENTAL_UPDATED__6pqcc16s_.bkp tag=INCREMENTAL_UPDATED_BU comment=NONE
(…)
channel ORA_DISK_1: starting incremental level 1 datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
including current control file in backup set
including current SPFILE in backup set
(…)
piece handle=/opt/app/oracle/recovery/ORA11G/backupset/2011_02_28/o1_mf_ncsn1_INCREMENTAL_UPDATED__6pqcd5cb_.bkp tag=INCREMENTAL_UPDATED_BU comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
Finished backup at 28 Feb 2011 15:13:26

Er zijn 2 incremental backupsets aangemaakt: 1 voor de datafiles en 1 voor de controlfile en spfile.

Dit heeft alles bij elkaar slechts 38 seconden geduurd.

Er verandert echter nog niets aan de inhoud van de image copies; de datum en key zijn nog exact hetzelfde:

RMAN> list copy of database;

List of Datafile Copies
=======================
Key     File S Completion Time      Ckp SCN    Ckp Time
------- ---- - -------------------- ---------- --------------------
10      1    A 28 Feb 2011 15:11:47 83692649   28 Feb 2011 15:11:37
Name: /opt/app/oracle/recovery/ORA11G/datafile/o1_mf_system_6pqc8s85_.dbf
Tag: INCREMENTAL_UPDATED_BU
(…)
12      7    A 28 Feb 2011 15:11:54 83692656   28 Feb 2011 15:11:53
Name: /opt/app/oracle/recovery/ORA11G/datafile/o1_mf_tools_6pqc99h7_.dbf
Tag: INCREMENTAL_UPDATED_BU

Pas bij het voor de derde keer uitvoeren worden daadwerkelijk de image copies bijgewerkt:

Starting recover at 28 Feb 2011 15:14:36
using channel ORA_DISK_1
channel ORA_DISK_1: starting incremental datafile backup set restore
channel ORA_DISK_1: specifying datafile copies to recover
recovering datafile copy file number=00001 name /opt/app/oracle/recovery/ORA11G/datafile/o1_mf_system_6pqc8s85_.dbf
recovering datafile copy file number=00002
(…)
channel ORA_DISK_1: reading from backup piece /opt/app/oracle/recovery/ORA11G/backupset/2011_02_28/o1_mf_nnnd1_INCREMENTAL_UPDATED__6pqcc16s_.bkp
channel ORA_DISK_1: piece handle=/opt/app/oracle/recovery/ORA11G/backupset/2011_02_28/o1_mf_nnnd1_INCREMENTAL_UPDATED__6pqcc16s_.bkp tag=INCREMENTAL_UPDATED_BU
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:01
Finished recover at 28 Feb 2011 15:14:38

En wordt er opnieuw een incremental backup gemaakt. Het recoveren en het maken van de nieuwe backup kost in totaal 37 seconden.

We zien nu dat de inhoud van de image copies is gewijzigd; de datum en de key zijn veranderd:

RMAN> list copy of database;

List of Datafile Copies
=======================
Key     File S Completion Time      Ckp SCN    Ckp Time
------- ---- - -------------------- ---------- --------------------
19      1    A 28 Feb 2011 15:14:37 83692725   28 Feb 2011 15:12:49
Name: /opt/app/oracle/recovery/ORA11G/datafile/o1_mf_system_6pqc8s85_.dbf
Tag: INCREMENTAL_UPDATED_BU
(…)
18      7    A 28 Feb 2011 15:14:37 83692725   28 Feb 2011 15:12:49
Name: /opt/app/oracle/recovery/ORA11G/datafile/o1_mf_tools_6pqc99h7_.dbf
Tag: INCREMENTAL_UPDATED_BU

Wat levert het nu voor winst op bij het uitvoeren van recovery? Om dit te testen voeren we een complete recovery uit. Allereerst herstellen we de database door gebruik te maken van de incremental updated backups:

RMAN> switch to database copy;
RMAN> recover database;

Dit hele proces duurt 33 seconden.

Als we nu de restore en recover uit willen voeren vanuit de backup, moeten we eerst de image copies op unavailable zetten:

RMAN> change copy of database unavailable;

Daarna kan de restore en recover uitgevoerd worden:

RMAN> run {
2  restore database;
3  recover database; }

Deze actie duurt 1 minuut en 43 seconden. Het gebruik van de incremental updated backups levert dus bij de restore van deze database een winst op van bijna 68%.

Het is ook mogelijk om eerst het backup commando en dan het recover commando op te geven. Dan wordt de image copy meteen bijgewerkt met de incremental backup. Voorwaarde hierbij is wel dat je dan een retention policy redunandancy 1 ingesteld moet hebben. Als je met een andere retention policy wil werken, moet er in het recover commando gebruik gemaakt worden van een UNTIL clausule.

Geïnteresseerd in nog meer RMAN wetenswaardigheden? Kom dan onze RMAN training volgen.