Using locally managed Oracle database as source and db_recovery_file_dest as archive logs destination

When you configure "db_recovery_file_dest" parameter, the "log_archive_dest_1" is set to "location=USE_DB_RECOVERY_FILE_DEST", which is pointing to the recovery destination. This is normal and is not the reason you face DMS replication task failures. The root cause of the issue you face is your database backup job, which probably deletes all the archivelogs once backed up. The recommendation is to retain archived logs for at least 24 hours to ensure the DMS replication tasks do not fail. Refer Using Oracle as a source.

Usually, custom RMAN backup scripts will have a "delete" command to cleanup archivelogs that are backed up to ensure the archive destination filesystem does not fill up.

An example RMAN backup command looks something like below:

run 
{
backup full database plus archivelog all not backed up;
delete noprompt archivelog all backed up 1 times to SBT_TAPE;
}

The above command performs a full database backup along with all the archivelogs not backed up earlier and deletes them once backed up. This will result in DMS replication task failures if it still needs some of the archivelogs that were backed up and deleted by the backup command.

To avoid this issue, modify the command to retain some of the archivelogs after backup. Retaining 24 hours archivelogs on disk may not be possible in some cases due to additional cost of storage. In such situations, try to retain the last few hours of archivelogs at least.

Modified example backup command from earlier to retain the last 4 hours of archived logs would look like below:

run 
{
backup full database plus archivelog all not backed up;
delete noprompt archivelog all completed before 'sysdate-4/24' backed up 1 times to SBT_TAPE;
}