This content has been marked as final. Show 3 replies
When you implement the FRA then the LOG_ARCHIVE_FORMAT is ignored and archive files are generated in OMF form. Since, at standby FRA is not implemented files will be generated as per LOG_ARCHIVE_FORMAT only and MRP process will be able to apply the archived log file on standby.
Even if FRA is implemented at both sides then also archive name generated at primary & standby are different and MRP is able to apply archives.
994692 wrote:There is no relationship with format of data files or archive log from primary to standby.
I have a Data Guard configuration with one primary and one physical standby. At the primary site, FRA is configured. For standby database, FRA is not configured. In our standby the parameter value is log_archive_format='% t_% s_% r.dbf'.
At the primary site, the generated filenames for the archived redo logs in the flash recovery area are Oracle Manged Filenames and are not determined by LOG_ARCHIVE_FORMAT
I would like to know how MRP process is able to identify the logs required for recovery?
Even primary can be on ASM and standby can be on non-ASM, Primary can be RAC and standby can be non-RAC. Now coming to your point.
Always standby deals with the couple of things,
1) Resetlogs_change# if this is same in both primary and standby then only you can function Data Guard.
2) and going forth it deals with thread number and the sequence number. So if the sequence 100 applied on standby then it knows what is the archive log sequence it has to apply, according to that it communicates to primary and it fetches 101 archive, So it concerns only on thread and sequence numbers.
3) SCN also plays key role, In case of real time apply the recovery occurs transaction to transaction when commit occurs.