Skip to main content

How To Enable Flash Recovery Area In Oracle Database

 The flash recovery area(FRA) is an Oracle-managed destination( either FILE SYSTEM or ASM ) for centralized backup and recovery files. It simplifies the backup management.

The following recovery-related files are stored in the flash recovery area:
— Current control file
— Online redo logs
— Archived redo logs
— Flashback logs
— Control file auto backups
— Datafile and control file copies
— Backup pieces
— Foreign archived redo log


Below are the steps for enabling flash recovery area.

DB_RECOVERY_FILE_DEST_SIZE and DB_RECOVERY_FILE_DEST initial parameters are required for enabling FRA.

DB_RECOVERY_FILE_DEST_SIZE -> It is the disk quota size for the flash recovery area.

DB_RECOVERY_FILE_DEST – > This initialization parameter is a valid destination for the Flash Recovery Area. It can be a directory, file system, or ASM disk group.

NOTE : DB_RECOVERY_FILE_DEST_SIZE must be set before DB_RECOVERY_FILE_DEST.

1. Check whether FRA is enabled or not.

SQL> show parameter db_recovery_file

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_recovery_file_dest string
db_recovery_file_dest_size big integer 0



SQL> select * from V$RECOVERY_FILE_DEST;

no rows selected2. Enable FRA.

2. Enable FRA.

SQL> alter system set db_recovery_file_dest_size=20G scope=both;

System altered.

SQL> alter system set db_recovery_file_dest='/dbaclassdb/oradata/FRA' scope=both;

System altered.


SQL> show parameter db_recovery_file

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_recovery_file_dest string /dbaclassdb/oradata/FRA
db_recovery_file_dest_size big integer 20G


select * from V$RECOVERY_FILE_DEST;
NAME SPACE_LIMIT SPACE_USED SPACE_RECLAIMABLE NUMBER_OF_FILES CON_ID
-------------------------------------- ----------- ---------- ----------------- --------------- ----------
/dbaclassdb/oradata/FRA 2.1475E+10 0 0 0 0  

Now FRA has been enabled.

How to make archivelog destination same as flash recovery area:

SQL> alter system set log_archive_dest_1='LOCATION=USE_DB_RECOVERY_FILE_DEST' scope=both;

System altered.

SQL> archive log list
Database log mode Archive Mode
Automatic archival Enabled
Archive destination USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence 816
Next log sequence to archive 818
Current log sequence 818
SQL> alter system switch logfile;

System altered.

1* select * from v$flash_recovery_area_usage
SQL> /

FILE_TYPE PERCENT_SPACE_USED PERCENT_SPACE_RECLAIMABLE NUMBER_OF_FILES CON_ID
----------------------- ------------------ ------------------------- --------------- ----------
CONTROL FILE 0 0 0 0
REDO LOG 0 0 0 0
ARCHIVED LOG .01 0 1 0
BACKUP PIECE 0 0 0 0
IMAGE COPY 0 0 0 0
FLASHBACK LOG .49 0 2 0
FOREIGN ARCHIVED LOG 0 0 0 0
AUXILIARY DATAFILE COPY 0 0 0 0

8 rows selected.
FOR RAC :
For RAC database, DB_RECOVERY_FILE_DEST_SIZE and DB_RECOVERY_FILE_DEST parameter must be same across all the instances. So it is recommended to put FRA on ASM DISKS.
SQL> alter system set db_recovery_file_dest_size=20G scope=both sid='*';

System altered.

SQL> alter system set db_recovery_file_dest='+FRADG' scope=both sid='*';

System altered.

Comments

Popular posts from this blog

Warning: long redo log write elapsed times detected, the LG* process tracefiles have more details

Warning: long redo log write elapsed times detected, the LG* process tracefiles have more details This warning means LGWR / LGnn background processes are taking too long to write redo to the online redo logs. It is usually related to one of these: - Slow storage / high I/O latency on redo log disks - Redo logs placed on busy disks together with datafiles, FRA, archive logs, backups, or OS files - Too many commits from the application, causing frequent LGWR flushes - Redo log size too small, causing frequent log switches - CPU scheduling issue, where LGWR is not getting CPU quickly - Data Guard synchronous transport delay, if using SYNC/AFFIRM - In newer 19c RU versions, especially around 19.28, this warning can appear more visibly because of diagnostic changes, so first confirm whether there is a real performance impact before changing anything. - Oracle’s own wait-event documentation says log file sync is the foreground wait for redo write confirmation after commit, and log file paral...

Convert TIMESTAMP to SCN and SCN to TIMESTAMP in Oracle

  Convert TIMESTAMP to SCN and SCN to TIMESTAMP in Oracle In many recovery scenario we need to know our SCN and timestamps. We can convert this by using the following function SCN_TO_TIMESTAMP TIMESTAMP_TO_SCN We can use this function with help of dual functions. Example of using this function as follows: 1. Convert the SCN to Timestamp SQL> select scn_to_timestamp(2011955) from dual; SCN_TO_TIMESTAMP(2011955) ----------------------------------------------------- 05-SEP-18 12.46.20.000000000 PM 2. Convert the Timestamp to SCN SQL> select timestamp_to_scn(to_timestamp('05-09-2018 12:46:21','dd-mm-yyyy hh24:mi:ss')) scn from dual; SCN ---------- 2011955