In Oracle 10g kan je gebruik maken van Automated Storage Management. (Zie ook Overzicht van ASM)Indien je hierbij gebruik maakt van RMAN flash area backups, kan het voorkomen dat de Recovery File Destination vol raakt,

als je niet periodiek backups maakt van je Flash Recovery Area en de grootte van de FRA niet groot genoeg is om de retentie periode in te herbergen. Indien de ruimte toch te vol raakt krijg je de volgende melding (voorbeeld) in de alert.log:

Tue Mar 10 10:10:10 2008
Errors in file /oracle/admin/SID/bdump/SID_arc1_5005.trc:
ORA-19815: WARNING: db_recovery_file_dest_size of 429496729600 bytes is 99.82% used, and
has 781680640 remaining bytes available.
************************************************************************
You have following choices to free up space from flash recovery area:
1. Consider changing RMAN RETENTION POLICY. If you are using Data Guard,
then consider changing RMAN ARCHIVELOG DELETION POLICY.
2. Back up files to tertiary device such as tape using RMAN
BACKUP RECOVERY AREA command.
3. Add disk space and increase db_recovery_file_dest_size parameter to
reflect the new space.
4. Delete unnecessary files using RMAN DELETE command. If an operating
system command was used to delete files, then use RMAN CROSSCHECK and
DELETE EXPIRED commands.
************************************************************************
Tue Mar 10 10:10:10 2008
Errors in file /oracle/admin/SID/bdump/SID_arc1_5005.trc:
ORA-19809: limit exceeded for recovery files
ORA-19804: cannot reclaim 1046327296 bytes disk space from 429496729600 limit
ARC1: Error 19809 Creating archive log file to '+ORADATA01'
ARC1: All standby destinations failed; successful archival assumed
ARC1: Failed to archive thread 1 sequence 517 (19809)
ARCH: Archival stopped, error occurred. Will continue retrying
Tue Mar 10 10:10:10 2008
ORACLE Instance SID - Archival Error
ARCH: Connecting to console port…

Als er geen extra ruimte meer is om aan de FRA toe te wijzen dan is waarschijnlijk je enige mogelijkheid nog om files uit je FRA te verwijderen.

Als je geen obsolete back-ups hebt, kan je deze ook niet meer weggooien, worden door rman weggegooid indien je een redundancy van 1 hebt ingesteld, als je alleen disk back-ups maakt kan je geen backup recovery area uitvoeren. In dit geval zal je dus de bestaande files in de FRA verwijderen en de recovery (on)mogelijkheden voor lief nemen. In ieder geval heb je wel snel de database weer online.

Het probleem is nu hoe je de files in de FRA verwijderd als deze op +ASM staat. De volgende voorbeelden laten stap voor stap de mogelijkheden zien:

Laat de +ASM files zien

Omdat het path gemoemd staat, kan deze vergeleken worden met de db_recovery_file_dest parameter en kan je er op die manier achter komen welke files de FRA beslaan:

COLUMN name Heading "Name" FORMAT A30 WORD_WRAPPED;
COLUMN path Heading "Path" FORMAT A60 WORD_WRAPPED;
COLUMN typ Heading "File Type" FORMAT A20;
BREAK ON typ SKIP 1 DUPLICATES;
SELECT al.name,
NVL(fi.type,'Directory') typ,
SYS_CONNECT_BY_PATH(al.name,'/') path
FROM v$asm_alias al,
v$asm_file fi
WHERE al.file_number = fi.file_number(+)
START WITH alias_index = 0
CONNECT BY PRIOR al.reference_index = al.parent_index
ORDER BY path, typ
/

Om de RMAN backup files van het type ARCHIVELOG en BACKUPSET weg te kunnen gooien, kan je de volgende 2 scripts uitvoeren en hun uitkomst spoolen zodat ze later geedit kunnen worden:

SELECT 'alter diskgroup '||dg.name||' drop file
''+'||dg.name||''||SYS_CONNECT_BY_PATH(al.name,'/')||''';'
FROM v$asm_alias al, v$asm_file fi, v$asm_diskgroup dg
WHERE al.file_number = fi.file_number(+)
AND al.group_number = dg.group_number
AND fi.type = 'ARCHIVELOG'
START WITH alias_index = 0
CONNECT BY PRIOR al.reference_index = al.parent_index

EN

SELECT 'alter diskgroup '||dg.name||' drop file
''+'||dg.name||''||SYS_CONNECT_BY_PATH(al.name,'/')||''';'
FROM v$asm_alias al, v$asm_file fi, v$asm_diskgroup dg
WHERE al.file_number = fi.file_number(+)
AND al.group_number = dg.group_number
AND fi.type = 'BACKUPSET'
START WITH alias_index = 0
CONNECT BY PRIOR al.reference_index = al.parent_index

Deze files kan je dus editen en uitvoeren. De gewenste files kan je dan van +ASM verwijderen.

Voorbeeld:

SQL SYSDBA> alter diskgroup ORADATA01 drop file '+ORADATA01/DBSID/1_12_542025636.arc';
Diskgroup altered.
SQL>

Als dit eenmaal is gedaan zal er nog een rman Crosscheck Archivelog All gedaan moeten worden zodat de discrepantie tussen de aanwezige logs op disk en de informatie die in de controlfile dan wel catalog, opgeslagen worden en op expired gezet :

RMAN> crosscheck archivelog all;1
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=150 devtype=DISK
allocated channel: ORA_DISK_2
channel ORA_DISK_2: sid=149 devtype=DISK
validation failed for archived log

Nu kan het rman delete expired archivelog all; commando gegeven worden zodat deze files van de rman repository of controlfile verwijderd kunnen worden:

RMAN> delete expired archivelog all;

De volgende query zal nu laten zien dat er weer genoeg ruimte in de FRA is:

SQL> select * from v$recovery_file_dest;
SQL> /

NAME SPACE_LIMIT SPACE_USED SPACE_RECLAIMABLE NUMBER_OF_FILES
-------------------- ----------------- --------------- ----------------- ---------------
+ORADATA01 429,496,729,600 87,896,880,640 7,340,032 37

Op dit punt is het belangrijk om een full backup van de database te maken zodat je er verzekerd van bent dat je deze weer kan recoveren