RMAN configuration suggestions to help save our storage space?

Question

To preface... Our Senior Oracle DBA has just recently passed away, and I've been taking over. My level of experience is just a junior level. So there is a lot I still don't understand. So I appreciate all the tips I can get, as this is a very frightening position for me.

Our technical issue... My company has just run out of storage space available in the mounted filesystem, and it is preventing us from recording backups any longer.

I have done my due diligence and cleaned up any obsolete data, but it did not help. The sys admin team is suggesting that we reduce the number of days that RMAN retains our backups. Retention Policy is currently set on default 7 days, I have considered changing this to 5, however 7 days just seems simpler as we hardly have any activity running over the weekend.

My question... What are your suggestions on things I can do to help clear up more space? What RMAN configurations should I consider looking through? Please advise with any thoughts...

We are running in archivelog mode, we are also doing incremental backups, (and full DB backups), all of which are failing and not recording backups due to the space issue. So there is currently no way to restore anything. Personally, I believe 7 days is ideal and simpler. Much easier to monitor when backups are recorded every weekend.

Answer 1

I have considered changing this to 5, however 7 days just seems simpler as we hardly have any activity running over the weekend.

I think you may be misunderstanding what that means.
Oracle will keep every file it needs to be able to Recover your database back to a point in time five days ago. You can take backups as often as you like during those five days and any that are no longer required will be automatically "dropped off".

So the question is not how long are you keeping backups for, but what kind of backups are you taking and how oftenare you taking them?

Also, what does your Recovery Strategy say? This document, agreed with Management, must include things like:

• How long you can take to get a broken database up and running again (formally, the Recovery Time Objective, RTO), and
• How much Data you're allowed to lose in doing so (the Recovery Point Objective, RPO).

Find these metrics and ask yourself - can your current setup support them?
If the answer in "No" then you have a very convincing argument to get more disk space, rather than trying to wriggle around in what you've got.

Answer 2

It was me who suggested you post here after you asked for help on Reddit. Phill has the most important point, he just explained it better than I did! You need to get the recovery strategy agreed. If you aren't familiar with the terms RTO and RPO, do a bit of study.

As I mentioned, a 7 day backup pattern may be simpler for you to manage, if you can manage the space requirements. But get the recovery requirements nailed down, then think about the best way to meet those requirements.

Answer 3

It sounds like the archive logs are being written to a different location than the backup files, else your instance would have hung when the backup area filled up.

Have you done a crosscheck recently? This brings the database's backup history up to date with what is on disk. The simplest way might be

catalog recovery area;

which I think does an implicit crosscheck, and will also tell you if there are any non-RMAN files in there.

You could check if you are using backup compression:

list backup summary device type disk;

The Compressed column will either say YES or NO. (Some always say NO, like control file autobackups I think.) Check what the RMAN configuration is with:

show all;

BASIC compression is the default and does not require a licence. NB Do not use LOW, MEDIUM, or HIGH compression unless you know you are licensed for the Advanced Compression option.

If BASIC compression is not being used, check the backup scripts. You might need to add the option

as compressed backupset

to the backup command. Check the Backup and Recovery Reference manual page for your version at https://docs.oracle.com before doing it.

How many databases are being backed up to the same FRA? Check what the database parameter DB_FILE_RECOVERY_DEST_SIZE is set to. In normal operation, Oracle will attempt to keep files in the FRA to 80% of this value while satisfying the RMAN RETENTION POLICY. I prefer to set DB_FILE_RECOVERY_DEST_SIZE smaller than the space available in the file system, so that there is somewhere to go if it hits 100%.

HTH