Forum Stats

  • 3,824,779 Users
  • 2,260,417 Discussions


RMAN configure backupset directory path

Ddalrymp-Oracle Member Posts: 1 Employee
edited Jul 29, 2020 6:03AM in Recovery Manager (RMAN)

Our service has been noticed growth of the fast_recovery_area backupset directory. We're pretty certain RMAN is doing what it is supposed to do and would like to know how to move it to another local disk which has more space.

Here is the current usage of the fast_recovery_area directory

189G ./app/oracle/fast_recovery_area/ORCL/backupset/2020_07_17

159G ./app/oracle/fast_recovery_area/ORCL/backupset/2020_07_14

156G ./app/oracle/fast_recovery_area/ORCL/backupset/2020_07_16

59G ./app/oracle/fast_recovery_area/ORCL/backupset/2020_07_18

41G ./app/oracle/fast_recovery_area/ORCL/backupset/2020_07_23

40G ./app/oracle/fast_recovery_area/ORCL/backupset/2020_07_22

40G ./app/oracle/fast_recovery_area/ORCL/backupset/2020_07_13

37G ./app/oracle/fast_recovery_area/ORCL/backupset/2020_07_25

36G ./app/oracle/fast_recovery_area/ORCL/backupset/2020_07_21

36G ./app/oracle/fast_recovery_area/ORCL/backupset/2020_07_11

One of the other things we're curious about is that there are three clear outliers for July 14, 16, and 17th. Is there any explanation for why the backupsets for those days are nearly 4x the size of neighboring dates? Are there any commands which would indicate if those backupsets could be reduced in size, cleaned up, etc.? Thanks.


  • EdStevens
    EdStevens Member Posts: 28,778 Gold Crown
    edited Jul 28, 2020 9:54AM

    Just moving files out of the FRA, while it will physically clear space, will not impact the FRA bookeeping.

    No one knows your system or what happened those four days.  Perhaps some 'one off' jobs generated a lot more DML than usual.

    Not only do we not know your system, we don't know your backup configurations (rman> show all) or your backup scripts.  How often do you take a level 0 vs. a level 1 backup?  Does your backup script include some variation of DELETE OBSOLETE?  Does it include a backup of the archivelogs, with some variation of the DELETE option for that?

  • Dude!
    Dude! Member Posts: 22,829 Black Diamond
    edited Jul 28, 2020 12:23PM

    Are you using any operating system? Looks like Unix or Linux to me.

    The default fast recovery area is $ORACLE_BASE/fast_recovery_area. So I suppose [...]/app/oracle is your ORACLE_BASE directory. I see not problem here. In fact, I suggest to leave the default and simply create a symbolic link that redirects FRA to where you want it to be.

    For example:

    ln -s /u03/fast_recovery_area /u01/app/oracle/fast_recovery_area

    To change your existing location, you simply copy the data to the new location, e.g. /u03/fast_recovery_area and when done delete the /u01/app/oracle/fast_recovery_area directory. Don't forget to check directory/file permissions.

    Then use the above ln -s command to create a symbolic link (soft link) accordingly. You don't need to change your database configuration. Every access to /u01/app/oracle/fast_recovery area will automatically, transparently and seamlessly go into /u03/fast_recovery_area.

    You will, however, need to change the FRA allocation size to match the new disk space.

    SQL> alter system set fast_recovery_area size 5000g

  • CristianR-Oracle
    CristianR-Oracle Member Posts: 497 Employee
    edited Jul 29, 2020 6:03AM

    Try below:

    RMAN> crosscheck backup;

    RMAN> crosscheck archivelogs all;

    RMAN> delete expired backup;

    RMAN> delete expired archivelogs all;

    RMAN> delete obsolete;

    Above will clear missing/not needed backup pieces.

    You can also mention the FORMAT parameter in your backup command to place the backup to some other location - other than FRA.