Using RMAN without catalog … watch out for DB Reboots!


I was always a fan of simplicity, and using rman with controlfile has proven to me to be suited for 99% of standalone databases of all sizes. But now I came to the conclusion that there is a huge flaw in this aproach, and since I felt it on my skin I feel obliged to share with you all.

I have a 180GB, 200 tx/sec database that does EM rman job backups, and has the space very limited for Flash Recovery Area. We do incremental backups everyday, switching from level 0 and level 1 day in day out. Last time we ran out of space because level 0 backup failed and in the next day was level 1 day, the retention policy is redundancy 1, kept the level 0, the level 1 and the new level 1, since the level 0 in between has failed.

Some one at the site tried to bounce the DB and that operation alone kept us from knowing what went wrong with the backup, because the rman logs are kept in memory and cleaned at each reboot. Since this information is not kept in the controlfile, pooof! We lost the rman output, and the oportunity to know what went wrong.

Here’s how you check this:

SQL> select count(*) from v$rman_output;

 COUNT(*)
----------
 34
SQL> startup force
ORACLE instance started.

Total System Global Area  426864640 bytes
Fixed Size                  1300352 bytes
Variable Size             247466112 bytes
Database Buffers          171966464 bytes
Redo Buffers                6131712 bytes
Database mounted.
Database opened.

SQL> select count(*) from v$rman_output

 COUNT(*)
----------
 0

Where’s my backup log info?? Gone baby gone.

Possible solutions for those who don’t want to use catalog:

1) Use a trigger on the V_$RMAN_OUTPUT view to keep track of all backup info on a separate table

2) Create a new schema on the same database and create a catalog there and dump this daily

3) Be a man and create a new DB for the catalog!

About these ads