5 things that aren’t true about RMAN

Introduction

RMAN backups are not a hot topic today. This is because it didn’t evolve that much in 12c/18c/19c, and most of the databases are now protected by a good backup strategy since years, and no changes are needed. Furthermore, Disaster Recovery solutions are more and more deployed, and all the flashback technologies embeded in the database are well known. This has pushed the need for RMAN restore to the very latest option in case of a failure. But we still do backups because we never know what could happen. Here are some untrue statements I heard recently about RMAN.

A full database RMAN backup is consistent

NO. A full database backup with RMAN is not consistent. Unless you shutdown the database, open it in the mount state and do the backup when the database is not open.

During an online backup, all the datafiles included in your backupsets will have different SCN, and you will never be able to restore a consistent database unless you have all the archivelogs between the beginning and the end of the backup.

Backup of database will take a certain amount of minutes or hours, and the more your backup will last, the less consistent will your backupsets be. But this is not a problem because you normally have all the archivelogs to put back the database in a consistent state, meaning all SCN aligned. Doing only a database backup at 10PM and lasting 1h will never let you restore a database consistent at any point in time if you don’t have the archivelogs. And an inconsistent database will never go from MOUNT to OPEN state. Having all the needed archivelogs will let you restore and recover the database at a point in time after 11PM. This is why the archivelogs are so important to backup.

Full backups should be done during the night

NO. There is no need to do database backups during the night. During the night, maintenance windows are planned (the default’s ones) and batches are probably running. You may think that doing a backup during the night will bring you a kind of consistency at the end of the day, but it’s very unlikely that you would need to do a restore at a point in time at the end of the day.

Either you will need a complete restore after a failure, or you will restore to a specific point in time.

Complete restore is needed when you loose some or all the datafiles. In this case, RMAN will pick up the files from the very latest full backup and apply all the changes in the archivelogs and will finish with the latest changes from the redologs.

Point-in-time restore/recover is something related to business, for example if someone corrupted data and did a commit, and if all flashback mechanisms cannot solve the problem. RMAN will then take the best full database backup to restore the database, the closest one before the problem and will apply all the changes from the archivelogs until the point-in-time you decided.

The start time of your full backup doesn’t really matter, you just need to plan it when the activity is rather low, when transactions and batches are rare.

Archivelogs backup can be done regularly, every hour for example. The most often you backup the archivelogs, the less files you will have to backup for each run.

RMAN backup is a good solution for Disaster Recovery

NO. A Disaster Recovery Plan means that you are able to bring back the database to life in a defined time. Most often a couple of minutes. Restoring a backup first needs a server, so if your current server is down, you will need another one. And restore will take time. The bigger your database is, the more time you will need to do the restore. Restoring a backup is much more a matter of time than anything else. And you may encounter troubles during the restore for some reasons, for example if something is missing in your backupsets.

Today, RMAN backups are still mandatory for critical databases, but 99.99% of the time you will use Disaster Recovery in case of failure, this is much more comfortable and it’s probably more compliant with your business requirements. Yes, your RMAN backupsets are mostly dedicated to the trash bin. This is not 100% true. Backups are still used for refreshing DEV or TEST databases, so you will probably use them from time to time!

Autobackup of the controlfile in the FRA is nice

NO. Autobackup of the controlfile is nice, but not in the Fast Recovery Area. It’s nice because it works beyond backup: each time a structural change on your database happens, an update of the controlfile is done and an automatic backup is triggered. This is very clever. But the default storage target for autobackup is in the FRA, which may not be your main backup destination. If you loose your database and also your FRA, you may not have the most recent controlfile to restore with minimal loss. FRA is the default destination for autobackup, and you can simply configure RMAN for putting this automatic backup in the backup folder of your daily full or incremental backup. This is definitely where it should be. If it’s not yet done, it’s easy to change, for example:

rman target /
CONFIGURE CONTROLFILE AUTOBACKUP ON; 
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO 'BackupPath_%F'; 

Backup speed depends on the disk speed

NO. Backup speed mainly depends on the parallel degree you choose to do the backup (the channels you allocate), and default is 1 channel only. This is the limit. If you’re using Standard Edition, you cannot go further and it’s one of the reason that makes Standard Edition not suitable for big databases (1+TB). When using Enterprise Edition, you will be able to allocate as many channel as you want (there is probably a limit), but you won’t probably allocate all available cores for this task. Increasing the number of channels will decrease the time needed for doing the backup, and increase consistency through datafiles in the backupsets. At some point, adding more channels will be useless because disks speed will then matter, either disks where your database resides, or disks where your backups reside (or their interface). Don’t forget that compressed backup will be more demanding for each channel, decreasing the overall backup speed.

Conclusion

One can discuss about Oracle database’s price compared to other RDBMS. But when it comes to reliability and resiliency, RMAN is a very strong argument for Oracle, don’t forget it.