db_recovery_file_dest full in standby database

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

db_recovery_file_dest full in standby database

raiq1
Dear Erman sir,

Hope you are fine there. recently we have implemented oracle dataguard setup in our environment, database is 19c with ebs 12.1.3

Daily we have monitored both primary & standby database and both are sync, today morning standby database archiving destination are full.

After implementation I have not deleted the archive log files in standby site.

Below are the error.



2022-11-09T00:40:27.300721+03:00
Errors in file /u01/app/oracle/diag/rdbms/prodcdbdr/PRODCDB/trace/PRODCDB_rfs_85738.trc:
ORA-19815: WARNING: db_recovery_file_dest_size of 536870912000 bytes is 100.00% used, and has 0 remaining bytes available.
************************************************************************
You have following choices to free up space from recovery area:
1. Consider changing RMAN RETENTION POLICY. If you are using Data Guard,
   then consider changing RMAN ARCHIVELOG DELETION POLICY.
2. Back up files to tertiary device such as tape using RMAN
   BACKUP RECOVERY AREA command.
3. Add disk space and increase db_recovery_file_dest_size parameter to
   reflect the new space.
4. Delete unnecessary files using RMAN DELETE command. If an operating
   system command was used to delete files, then use RMAN CROSSCHECK and
   DELETE EXPIRED commands.
************************************************************************
ORA-19809: limit exceeded for recovery files
ORA-19804: cannot reclaim 1074790400 bytes disk space from 536870912000 bytes limit
2022-11-09T00:41:27.644514+03:00
 rfs (PID:87825): krsr_rfs_atc: Identified database type as 'PHYSICAL STANDBY': Client is Foreground (PID:93563)


After that I have deleted old archive files from standby side and manage the space.

Is it possible that after archiving are applied from production to standby database , archive files are deleted automatically or we have retain 3 days archive files and rest all should delete.


Kindly need your advice .

Regards,
Raiq.



Reply | Threaded
Open this post in threaded view
|

Re: db_recovery_file_dest full in standby database

ErmanArslansOracleBlog
Administrator
What you need is a mechanism that automatically purges archivelogs from the FRA once they are applied to the standby database.
Yes, you can do that.

See -> Configure RMAN to purge archivelogs after applied on standby (Doc ID 728053.1)
Reply | Threaded
Open this post in threaded view
|

Re: db_recovery_file_dest full in standby database

raiq1
Hi Erman sir,

As per your advice, I have read the document 728053.1

there is a doubt and need to understand.

RMAN> CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY;

what about below command.

RMAN> CONFIGURE ARCHIVELOG DELETION POLICY TO SHIPPED TO STANDBY;

Need to know for both the commands which one are prefer in my environment , In standby we are not taking a backup of standby database because it is a mount mode.

Kindly advice.

Regards,
Raiq
Reply | Threaded
Open this post in threaded view
|

Re: db_recovery_file_dest full in standby database

ErmanArslansOracleBlog
Administrator
shipped -> transferred to standby but not applied yet
applied -> transferred to standby and applied .
Reply | Threaded
Open this post in threaded view
|

Re: db_recovery_file_dest full in standby database

raiq1
Dear erman sir,

if I configure to applied option, how it works. after it shipped and applied , all the archive files are deleted automatically after FRA reached 80% or when  it will delete on which threashold. Kindly explain.

Regards,
Raiq
Reply | Threaded
Open this post in threaded view
|

Re: db_recovery_file_dest full in standby database

ErmanArslansOracleBlog
Administrator
%80? There is no magic number like that. When there is a space processor, the deletion process comes in..
There is certain percentage for that, but according to the what I see and read it is around %85.. --> Test it on your env.

Facts:

Only archived redo log files in the fast recovery area are automatically deleted by the database.
In that process, you may see ORA-19815 reported in your alert log, if that bothers you, you can also consider doing a manual cleanup as a part of your backup procedure.