Archive Logs Missing in Oracle Exadata Cloud @ Customer (ExaCC) or Oracle Exadata Cloud Service (ExaCS) Environments

Apr 1, 2026

By Vijay Muthu

Archive logs play a crucial role in ensuring data protection and recovery in Oracle Exadata Cloud @ Customer (ExaCC) and Oracle Exadata Cloud Service (ExaCS) environments. However, many administrators are puzzled when these logs suddenly go missing, even when standard backup and deletion settings appear disabled.

In this blog post, we’ll explore the underlying reasons for unexpected archive log deletions, discuss typical scenarios where this issue arises, and provide actionable guidance to help you diagnose and resolve the problem efficiently.

Specifically, this guide explains why archive logs may be automatically deleted even when:

No automatic backups enabled in the OCI Console, and
No archive log deletion policy is configured in RMAN.

Issue Summary

Customers may observe that archive logs are being deleted from the Fast Recovery Area in ExaCC/ExaCS.

Causes of Automation Deletion of Archive Logs

In some cases, a hidden FRA_CLEANUP schedule, managed internally by dbaascli, may be active. This background task can automatically delete archive logs based on internal configuration settings.

How to Identify the Issue

Check for OS-level cron jobs

cat /etc/crontab

Check hidden schedules

dbaascli database backup --dbname<dbname> --getSchedules

If FRA_CLEANUP appears as ACTIVE, the cleanup job is running.
Review job history

dbaascli database backup --dbname<dbname> --showhistory --all

Check logs

/var/opt/oracle/log/dtrs/jobs/
This directory contains log files corresponding to the UUID displayed in the --showhistory command, confirming archive log deletions.

Resolution Steps

Note: For some dbaascli versions, Option 1 may not work.

Option 1: Disable FRA_CLEANUP via Configuration File

Generate the backup configuration file:

dbaascli database backup --dbName<db_name> --getConfig

Edit the generated configuration file located under:

/var/opt/oracle/log/dtrs/staging/tmpl/

Update the following entries:

Change bkup_archlog_cron_entry=yes → bkup_archlog_cron_entry=no OR
Change manageArchivelogs=yes → manageArchivelogs=no

Apply the updated configuration:

dbaascli database backup --dbName<db_name> --setConfig --configfile<config_file_path>

Restart the DTRS service (no database impact):

systemctl stop initdcsdtrs
systemctl start initdcsdtrs

Verify that FRA_CLEANUP is no longer ACTIVE.
If FRA_CLEANUP is still active and is the only schedule displayed in --getSchedules, delete it:

dbaascli database backup --dbname<dbname> --deleteschedules

Option 2: Disable Specific Schedules (When Multiple Schedules Exist)

locate creg|grep-i<dbname>

Fetch the agentdbid from the .ini file.
Navigate to schedule models:

cd /var/opt/oracle/dbaas_acfs/dtrs/schedules/ScheduleModel

Identify the JSON file associated with the agentdbid:

grep-ir<agentdbid>*.json

Edit the JSON file to set the FRA_CLEANUP schedule to INACTIVE.
Validate the schedule:

dbaascli database backup --dbname<dbname> --getSchedules

Important Considerations

Before disabling archive log management:

Ensure that a proper backup strategy is implemented.
Disabling cleanup without sufficient FRA space planning may result in space pressure issues.

Validation Checklist

FRA_CLEANUP schedule is no longer ACTIVE
Archive logs are retained as expected
Backup configuration is validated
DTRS service restarted successfully
Archive Log Deletion Policy is enabled in RMAN

Careful planning and validation are essential when making changes to archive log management. By following these important considerations and checklist items, you can help ensure the stability and effectiveness of your database environment.

Get more database resources at Datavail.com.