Failed to request gap sequence notification in Alert Log - Oracle Database

CONTROL_FILE_RECORD_KEEP_TIME initialization parameter in Oracle Database

CONTROL_FILE_RECORD_KEEP_TIME initialization parameter

I noticed this parameter in the Alert Log when I was doing the DR Recovery. The backup in use was taken by RMAN incremental backup using SCN value. I restored the Standby controlfile created from the Primary and made the necessary modifications in the same like changing the path for datafiles in the controlfile as the structure was completely different from what I had in my Primary Oracle Database. The Primary database was 2 Node RAC (Real Application Cluster) Architecture configured on ASM (Automatic Storage Management) and then we had 2 DR Sites for the same. One of the 2 physical standby databases was also 2 Node RAC Architecture configured using ASM and the 2nd DR was on single instance. I was recovering the single instance DR when I noticed the below mentioned lines in my Oracle Database Alert Log:

FAL[client]: Failed to request gap sequence  GAP - thread 2 sequence 235062-235062  DBID 2807489448 branch 780950056
FAL[client]: All defined FAL servers have been attempted.
------------------------------------------------------------
Check that the CONTROL_FILE_RECORD_KEEP_TIME initialization parameter is defined to a value that's sufficiently large enough to maintain adequate log switch information to resolve archivelog gaps.
------------------------------------------------------------

Problem:-

It was observed that the day when the incremental backup was taken and the day when the recovery operation was performed had the difference of 10 days. Which means we were performing the recovery operation after 10 days of taking the backup. Now CONTROL_FILE_RECORD_KEEP_TIME parameter has a default value of 7 (in days), which can be altered (0-365 days) but was default in our case and hence control file has lost the necessary information to proceed with the recovery since it wasn't able to request the gap sequence because of the lost information.

How we resolved it?

We made the change in the CONTROL_FILE_RECORD_KEEP_TIME parameter and set the value to 15 days (in order to avoid the same issue in future) and again took the fresh incremental backup to recover the DR Site.