Thanks for the question, John.
Asked: March 04, 2021 - 2:28 pm UTC
Last updated: March 05, 2021 - 5:27 am UTC
Version: 19c
Viewed 1000+ times
You Asked
Greetings,
My question involves the use of the FAST RECOVERY AREA for online redo logs and even controlfiles. Typically, the backup mount points are on slower disks. Therefore, if we were to set DB_RECOVERY_FILE_DEST to that backup mount, my assumption is that Oracle wouldn't recommend placing online redo logs on those slower backup mounts.
Also, if we place the control files, now we would decreasing the fault tolerance. The storage backup admin could decide to do some maintenance on the backup system and forget to coordinate with the DBA.
I'm just trying to understand when it is a good idea to use FAST RECOVERY AREA and when it is not. I've been working with Oracle for over 20 years and not using FAST RECOVERY AREA has worked out great for me.
"When you enable fast recovery in the init.ora file, Oracle Database writes all RMAN backups, archive logs, control file automatic backups, and database copies to the fast recovery area." Oracle 18c documentation
Thanks for your help,
John
and Connor said...
DB_RECOVERY_FILE_DEST for "everything" is more a recognition of the way databases have been allocated storage (via file system or ASM) over recent years, namely, a big bucket of disks are put into a volume and everything sits on them. The distinction between types of storage and types of files is becoming less and less common for databases. In terms of resilience, DB_RECOVERY_FILE_DEST is still (typically) going to be on a mirrored/striped volume (ASM or otherwise).
That said, this is just a *default*. There is nothing to stop you (and it is a common practice) that DBAs still place their datafiles/controlfile/redofiles in locations of their choosing, and then use DB_RECOVERY_FILE_DEST as a mechanism of simplifying the management of backups etc.
The choice is yours.
Is this answer out of date? If it is, please let us know via a Comment