• Flash Recovery Area Fast Incremental Backups
• Incrementally Updated Backups
• Fast Incremental Backups
• BACKUP for Backupsets and Image Copies
• Cataloging Backup Pieces
• Improved RMAN Reporting Through V$ Views
• Automatic Instance Creation for RMAN TSPITR
• Cross-Platform Tablespace Conversion
• Enhanced Stored Scripts Commands
• Backupset Compression
• Restore Preview
• Managing Backup Duration en Throttling
• Overige
  • Disk Topology en Automatic Performance Tuning
  • Automatic Datafile Creation
  • Proxy Archived Log Backups
  • Recovery Through Restlogs
  • Restore Failover
  • Channel Failover
  • Deferred Error Reporting

Flash Recovery Area

De flash recovery area is een locatie op het filesysteem of op een ASM disk group die files bevat die zijn gerelateerd aan recovery waaronder:

• Multiplexed controlfiles
• Multiplexed online redo logs
• Archived redo logs
• Flashback logs
• RMAN disk backups
• Files gemaakt door RESTORE en RECOVERY commando’s.

Ruimte binnen de flash recovery area wordt gemanaged door de database. Als er niet genoeg ruimte is om een actie te voltooien dan zullen files die verouderd zijn, waar een back up van gemaakt is of overbodig zijn, worden verwijderd om ruimte vrij te maken.

Het volgende voorbeeld laat de parameters zien die worden gebruikt om de flash recorvery area te configureren.

ALTER SYSTEM SET DB_RECOVERY_FILE_DEST = '/u01/app/oracle/flash_recovery_area';
ALTER SYSTEM SET DB_RECOVERY_FILE_DEST_SIZE = 2G;
ALTER SYSTEM SET DB_FLASHBACK_RETENTION_TARGET = 1440;

De flashback technieken worden besproken in het artikel Flashback New Features en verbeteringen in Oracle database 10g .

Incrementally Updated Backups
Alle veranderingen tussen het SCN van de originele image copy en het SCN van de incremental back up worden met dit onderdeel toegepast op de image copy om een equivalent van een nieuwe database image copy te maken zonder de overhead van zo een back up. Het volgende voorbeeld laat zien hoe dit kan worden gebruikt.

RUN {
RECOVER COPY OF DATABASE WITH TAG 'incr_backup' UNTIL TIME 'SYSDATE - 7';
BACKUP INCREMENTAL LEVEL 1 FOR RECOVER OF COPY WITH TAG 'incr_backup' DATABASE;
}

Na 7 dagen zal de zin RECOVER COPY effect beginnen te krijgen, en voegt alle incremental back-ups ouder dan 7 dagen samen in de level 0 back up, die effectief de level 0 back up naar voren verplaatst. Het effect hiervan is dat je permanent een 7 dagen recovery window hebt met een 7 dagen oude level 0 back up an 6 level 1 incremental back ups. Denk eraan dat de tag gebruikt moet worden om aan te geven welke incremental back-ups toegevoegd moet worden aan welke image copy.

Als je je image copy zo up to date mogelijk wilt houden, kan je het volgende doen:

RUN {
BACKUP INCREMENTAL LEVEL 1 FOR RECOVER OF COPY WITH TAG 'incr_backup' DATABASE;
RECOVER COPY OF DATABASE WITH TAG 'incr_backup';
}

In dit voorbeeld wordt de incremental back-up samengevoegd in een image copy zodra deze gereed is.

Fast Incremental Back-ups

Er zijn performance issues die samenhangen met incremental back-ups omdat iedere datafile in zijn geheel op veranderde blokken moet worden gescanned. In Oracle 10g is het mogelijk is het mogelijk om alle veranderde blokken bij te houden in een file “BLOCK_CHANGE_TRACKING”. Het aanzetten van change tracking geeft een kleine overhead maar het verbeterd de performance van incremental back-ups aanzienlijk. De huidige “change tracking status”kan gezien worden in de volgende query:

SELECT status FROM v$block_change_tracking;

Change tracking word aangezet met het ALTER DATABASE commando:

ALTER DATABASE ENABLE BLOCK CHANGE TRACKING;

Als default wordt de change tracking file aangemaakt als een Oracle Managed File (OMF) in de location die gezet is in de DB_CREATE_FILE_DEST parameter. Een alternatieve locatie kan aangegeven worden met het volgende commando:

ALTER DATABASE ENABLE BLOCK CHANGE TRACKING 
USING FILE '/u01/oradata/MYSID/rman_change_track.f' REUSE;

De tracking file wordt aangemaakt met een minimum grootte van10M en groeit met 10M per keer. Zijn grootte is normaal gesproken 1/30,000 van de grootte van de datablocks die getrackt moeten worden.

Change tracking kan op de volgende manier uitgezet worden:

ALTER DATABASE DISABLE BLOCK CHANGE TRACKING;

Hernoemen of verplaatsen van een tracking file kan met het ALTER DATABASE RENAME FILE commando. Als de instance niet herstart kan worden kan j eenvoudig change tracking uitzetten en weer aanzetten met een andere naam zodat een nieuwe file wordt aangemaakt. Dit heeft echter wel tot gevolg dat de huidige change informatie verloren gaat.

BACKUP for Backupsets and Image Copies

In Oracle 10g is het BACKUP commando uitgebreid. Om naast back-upsets ook image copies te initiëren. Het gevolg hiervan is dat het COPY commando is weggevallen ten faveure van de volgende syntaxis.

BACKUP AS COPY DATABASE;
BACKUP AS COPY TABLESPACE users;
BACKUP AS COPY DATAFILE 1;

RMAN support de creatie van image copies van datafiles en datafile copies, control files en controlfile copies, archived redo logs, en backup pieces.

Cataloging Backup Pieces

Het is nu mogelijk om handmatig een back-up piece aan de catalog toe te voegen met het

CATALOG commando in RMAN. Op deze manier kunnen back-up files verplaatst worden naar andere locaties of handmatig gearchiveerd worden naar tape en teruggehaald worden voor restore operatie. In Oracle 9i was deze functionaliteit alleen aanwezig voor de controlfile copies en datafile copies. Opvolgend hieraan zijn er een aantal shortcuts wat het mogelijk maakt om meerdere files in een commando in de catalog op te nemend. Het volgende voorbeeld geeft een idee:

# Catalog specific backup piece.
CATALOG BACKUPPIECE '/backup/MYSID/01dmsbj4_1_1.bcp';

# Catalog all files and the contents of directories which
# begin with the pattern "/backup/MYSID/arch". 
CATALOG START WITH '/backup/MYSID/arch';

# Catalog all files in the current recovery area.
CATALOG RECOVERY AREA NOPROMPT;

# Catalog all files in the current recovery area.
# This is an exact synonym of the previous command.
CATALOG DB_RECOVERY_FILE_DEST NOPROMPT;

De NOPROMPT clause zorgt ervoor dat er geen confirmation nodig is van de user voor alle ‘matching’ files.

Improved RMAN Reporting Through V$ Views

Oracle 10g bevat een aantal extra V$ views wat de rapportage van backup operaties meer transparant maakt.

• V$RMAN_OUTPUT – Dit is een view van de berichten van RMAN met een maximum van 32767 rijen die in het geheugen wordt opgeslagen. Omdat deze informatie niet in de controlfile wordt opgeslagen zal het verloren gaan als de instance herstart wordt.
• V$RMAN_STATUS - Deze view laat progressieve en status informatie zien voor RMAN jobs die bezig zijn of completed. Die jobs die nog lopen zijn in het geheugen opgeslagen terwijl de status van de job die completed is uit de controlfile komt. V$BACKUP_FILES – Deze view laat informatie zien over RMAN image copies, back-upsets en archived logs, vergelijkbaar met RMAN commando LIST BACKUP en LIST COPY. Deze view haalt zijn gegevens uit de DBMS_RCVMAN.SETDATABASE procedure die gebruikt wordt om de database te zetten.

De V$RMAN_CONFIGURATION view van Oracle 9i is in Oracle 10g.nog steeds beschikbaar.

Automatic Instance Creation for RMAN TSPITR

Als een tablespace point-in-time recovery (TSPITR) wordt aangeroepen zonder referentie naar een auxillary instance zal RMAN er automatisch een creëren. De auxillary instance configuratie wordt gebaseerd op die van de target database. Voorwaarde is wel dat de channels die nodig zijn voor de restore operatie in de target database aanwezig zijn zodat ze op de juiste wijze worden geconfigureerd in de. De locatie van de datafiles voor de auxillary instance worden met de AUXILIARY DESTINATION clause gespecificeerd als onder:

RECOVER TABLESPACE users 
UNTIL LOGSEQ 2400 THREAD 1
AUXILIARY DESTINATION '/u01/oradata/auxdest';

De tablespace is offline gehaald, gerestored van een back-up, recovered naar een gespecificeerd point in time in de auxillary instance en weer geïmporteerd in de target database. De tablespace in the target database zou dan wel geback-upt moeten worden en de tablespace weer online gebracht.

BACKUP TABLESPACE users;
SQL "ALTER TABLESPACE users ONLINE";

Indien succesvol zal de auxillary instance weer automatisch opgeschoond worden. Als er errors optreden zal de auxillary instance intact blijven om te kunnen helpen bij troubleshooting.

Cross-Platform Tablespace Conversion

De CONVERT TABLESPACE maakt het mogelijk om tablespaces over verschillende platformen met verschillende byte orders te transporteren. Het mechanisme voor het transporteren van een tablespace is ongewijzigd gebleven, dit commando converteert de tablespace slechts om er voor te zorgen dat de transport ook werkt.

Het platform van de bron en de target worden bekeken in de view V$TRANSPORTABLE_PLATFORM. Het platform van de lokale server is niet te zien als er geen conversie nodig is.

SQL> SELECT platform_name FROM v$transportable_platform;

PLATFORM_NAME
------------------------------------
Solaris[tm] OE (32-bit)
...
...
Microsoft Windows 64-bit for AMD

15 rows selected.

De tablespace conversie kan plaatsvinden op zowel de bron als de target. Het volgende voorbeeld laat zien hoe het commando gebruikt moet worden:

# Conversion on a Solaris source host to a Linux destination file.
CONVERT TABLESPACE my_tablespace
TO PLATFORM 'Linux IA (32-bit)'
FORMAT='/tmp/transport_linux/%U';

# Conversion on a Linux destination host from a Solaris source file.
CONVERT DATAFILE=
'/tmp/transport_solaris/my_ts_file01.dbf',
'/tmp/transport_solaris/my_ts_file02.dbf'
FROM PLATFORM 'Solaris[tm] OE (32-bit)'
DB_FILE_NAME_CONVERT
'/tmp/transport_solaris','/u01/oradata/MYDB';

In het eerste voorbeeld worden de geconverteerde files in de directory geplaatst welke door de FORMAT clause.wordt gespecificeerd. In het 2de voorbeeld worden de gespecificeerde datafiles geconverteerd naar de lokale server en geplaatst in de juiste directory met de DB_FILE_NAME_CONVERT clause.

Enhanced Stored Scripts Commands

Scripts kunnen nu als global gedefinieerd worden zodat ze door alle databases in de recovery catalog kunnen worden gebruikt, De syntax voor global script manipulatie is hetzelfde als voor de gewone scripts met de toevoeging van de GLOBAL clause vaarafgaand aan het woord SCRIPT.

Voorbeelden van het gebuik:

CREATE GLOBAL SCRIPT full_backup 
{
BACKUP DATABASE PLUS ARCHIVELOG;
DELETE FORCE NOPROMPT OBSOLETE;
}

CREATE GLOBAL SCRIPT full_backup FROM FILE 'full_backup.txt';

RUN { EXECUTE GLOBAL SCRIPT full_backup; }

PRINT GLOBAL SCRIPT full_backup;

LIST GLOBAL SCRIPT NAMES;
LIST ALL SCRIPT NAMES; # Global and local scripts.

REPLACE GLOBAL SCRIPT full_backup 
{
BACKUP DATABASE PLUS ARCHIVELOG;
DELETE FORCE NOPROMPT OBSOLETE;
}

REPLACE GLOBAL SCRIPT full_backup FROM FILE 'full_backup.txt';

DELETE GLOBAL SCRIPT 'full_backup';

Backupset Compression

De AS COMPRESSED BACKUPSET optie van het BACKUP commando zorgt ervoor dat RMAN binaire compressie kan toepassen voor back-upsets. De back-upsets die ontstaan hoeven bij recovery niet te worden uncompressed. Het is het meest toepasbaar onder de volgende omstandigheden:

<!--Maken van back-ups naar disk met gelimiteerd de disk ruimte.

<!-- Maken van back-ups over een netwerk waar de bandbreedte is gelimiteerd.

<!--Maken van back-ups naar tape, CD of DVD waar hardware compressie niet beschikbaar is.

Bij de volgende voorbeelden gaan we ervan uit dat een aantal parameters die gebleven zijn, geconfigureerd zijn als onder:

CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;
CONFIGURE DEFAULT DEVICE TYPE TO DISK;
CONFIGURE CONTROLFILE AUTOBACKUP ON;
CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '/backups/MYSID/%d_DB_%u_%s_%p';

De AS COMPRESSED BACKUPSET optie kan alleen maar in het back-up commando gebruikt worden:

# Whole database and archivelogs.
BACKUP AS COMPRESSED BACKUPSET DATABASE PLUS ARCHIVELOG;

# Datafiles 1 and 5 only.
BACKUP AS COMPRESSED BACKUPSET DATAFILE 1,5;

De optie compressed kan gedefinieerd worden met het CONFIGURE commando:

# Configure compression.
CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO COMPRESSED BACKUPSET;

# Whole database and archivelogs.
BACKUP DATABASE PLUS ARCHIVELOG;

Compressie heeft wel extra CPU cycles nodig wat de performance van de database enigszins kan beïnvloeden. Om deze reden zou het niet gebruikt moeten worden bij tape back-ups waar hardware compressie aanwezig is.

Restore Preview

De PREVIEW optie van het RESTORE commando maakt het mogelijk om te onderzoeken welke back-ups nodig zijn om een bepaalde restore actie uit te kunnen. De output welke gegenereerd wordt is dezelfde als bij het LIST commando. Als extra kan het PREVIEW SUMMARY commando gebruikt worden om een samenvatting te maken met het zelfde formaat als het LIST SUMMARY commando. De volgende voorbeelden laten zien je ze kan gebruiken:

# Preview
RESTORE DATABASE PREVIEW;
RESTORE TABLESPACE users PREVIEW;

# Preview Summary
RESTORE DATABASE PREVIEW SUMMARY;
RESTORE TABLESPACE users PREVIEW SUMMARY;

Managing Back-up Duration and Throttling

De DURATION clause van het BACKUP commando zet een beperking op de totale tijd dat een back-up mag lopen om te completen. Aan het eind van de tijd-window wordt de back-up onderbroken en de incomplete back-upsets worden genegeerd. Alle complete back-upsets worden bewaard en gebruikt voor toekomstige restore operaties.

Voorbeeld hoe je ze kan gebruiken:

BACKUP DURATION 2:00 TABLESPACE users;
BACKUP DURATION 5:00 DATABASE PLUS ARCHIVELOGS;

Overige

• Disk Topology en Automatisch Performance Tuning - RMAN beschikt over een nieuwe disk topologie API zodat er met meer platforms en file typen gewerkt kan worden. De informatie van deze API stelt RMAN in staat om automatisch een aantal parameters die gerelateerd zijn aan “multiplexing” en disk buffers te tunen zodat menselijke tussenkomst verminderd kan worden.
• Automatic Datafile Creation - RMAN zal in de volgende gevallen, automatisch missende datafiles creëren:
  Als de back-up controlfile refereert aan een datafile maar er geen back-up van deze datafile aanwezig is.
  En wanneer de back-up van een datafile er wel is maar er geen referentie is in de controlfile omdat hij niet geback-upt was na de datafile creatie.
• Proxy Archived Log Backups – Tijdens een proxy back-up zal de media manager het back-up proces volledig controleren. RMAN kan nu proxy copies van archived logs back-uppen en restoren als het gebruik maakt van een geschikte media manager. Als er geen geschikte media manager beschikbaar is zal de PROXY clause genegeerd worden en een reguliere back-up wordt uitgevoerd. Indien gebruik gemaakt wordt van de PROXY ONLY clause zal de back-up resulteren in een error en de proxy back-up kan niet uitgevoerd worden.
• Recovery Through Resetlogs - RMAN staat het nu toe om het restore proces door te laten lopen door verschillende incarnaties heen. De inhoud van de redologs zal worden gearchiveerd voor ze worden geschoond als een OPEN RESTLOGS wordt uitgevoerd. Het resultaat is dat er na een OPEN RESTLOGS aktie er geen back-up gemaakt hoeft te worden.
• Restore Failover – Als een back-up file corrupte blokken bevat of niet toegankelijk is tijdens een restore aktie (RECOVER, BLOCKRECOVER, en FLASHBACK DATABASE) zal RMAN automatisch zoeken naar andere kopieën van de file. Als er geen een beschikbaar is, zal RMAN een oudere versie van de file gebruiken als die beschikbaar is. Alleen al er geen geschikte kopie van de file gevonden kan worden, zal RMAN met een foutmelding terugkomen. Een succesvolle failover operatie zal resulteren in een overeenkomstige melding.
• Channel Failover – Als er meerder channels beschikbaar zijn voor hetzelfde device zullen fouten die nogmaals uitgevoerd kunnen worden in een back-up step, automatisch op een andere channel uitgevoerd worden. Opnieuw uitvoerbare fouten zie je mestal bij met media managers die en tape niet kunnen benaderen of instance fouten in RAC omgevingen.
• Deferred Error Reporting – Aanvullend op de foutmeldingen tijdens de uitvoer van de job, zal de foutmelding aan het eind van het commando, foutmeldingen laten zien over alle onderdelen die fout gelopen zijn zodat de foutopsporing makkelijker zal worden.