Managing Archive Logs in RDS for Oracle

If you've worked with Oracle on AWS RDS, you've probably run into the quirks of dealing with archive logs in a managed environment. Unlike a self-managed Oracle instance where you have full OS access, RDS keeps you at arm's length from the underlying file system — and for good reason. But that also means you need to know the right tools and approaches to manage archive logs effectively. Here's what I've learned from working through these scenarios.

Understanding How RDS Manages Archive Logs

The first thing to wrap your head around is that RDS is a managed engine. AWS handles the heavy lifting around backups and archive logs, and the retention of both is controlled through their respective retention settings. You're not going to SSH into the host and poke around the file system — that access simply doesn't exist.

Instead, AWS exposes the rdsadmin.* package, which gives you a way to interact with internals from the SQL prompt. Once I discovered this, a lot of things clicked into place.

Listing Files Inside RDS

Since you can't browse the file system directly, the rdsadmin.rds_file_util.listdir package is your go-to for seeing what's actually on disk.

List archive logs:

SELECT * FROM TABLE(rdsadmin.rds_file_util.listdir(p_directory => 'ARCHIVELOG_DIR'));

List files in the Data Pump directory:

SELECT * FROM TABLE(rdsadmin.rds_file_util.listdir(p_directory => 'DATA_PUMP_DIR'));

List trace files:

SELECT * FROM rdsadmin.tracefile_listing;
SELECT * FROM TABLE(rdsadmin.rds_file_util.listdir('BDUMP'));

Read the contents of a log file (handy when you're chasing down errors):

SELECT text FROM TABLE(rdsadmin.rds_file_util.read_text_file('BDUMP', 'alert_dbname.log.date'));

These queries have saved me a lot of time when I needed to verify what was actually present in the archive directory before jumping to conclusions about missing logs.

Reference: AWS RDS Oracle Log Access Docs

The DMS Archive Log Problem

One of the most frustrating situations I've encountered is when using AWS DMS (Database Migration Service) for CDC (Change Data Capture) from an Oracle RDS source, and the archive logs disappear before DMS gets a chance to read them.

The error looks something like this:

03980512: 2022-05-23T12:33:11 [SOURCE_CAPTURE ]E: Archived Redo log with the sequence 232488
does not exist, thread 1 [1022318] (oradcdc_thread.c:624)

This happens when the archive log retention period is shorter than the replication lag — meaning logs are getting cleaned up before DMS can consume them. Here's how I approach recovering from this.

Checking and Adjusting Archive Log Retention

The first thing to do is check what your current retention period is set to:

EXEC rdsadmin.rdsadmin_util.show_configuration;

If the retention is too short (or not set at all), you'll want to increase it. For example, to set it to 24 hours:

BEGIN
  rdsadmin.rdsadmin_util.set_configuration(
    name  => 'archivelog retention hours',
    value => '24'
  );
END;
/
COMMIT;

Replace 24 with whatever value makes sense for your workload — ideally something greater than your current replication lag to give DMS enough runway.

Tip: Don't set this higher than necessary. Archive logs take up space, and in RDS that space is your allocated storage. I've seen environments run into storage pressure because someone cranked retention up to 168 hours (7 days) and forgot about it.

Recovering Lost Archive Logs

If the logs are already gone, you have a few options depending on your backup situation.

Option 1 — Restore from RDS backup: If your RDS backup retention is still covering the point-in-time you need, the archive logs may still be accessible in S3. AWS makes archived redo logs available for download in some scenarios.

Reference: Downloading archived redo logs from Amazon S3

Option 2 — Restart the DMS task from a new SCN: If log recovery isn't viable, the cleanest path is often to reload the affected tables and restart CDC from a fresh snapshot. It's painful, but it avoids chasing a moving target with missing logs.

For additional guidance on DMS sequence and performance errors:

• AWS: Resolve DMS sequence errors for CDC on Oracle
• AWS: Resolve DMS performance errors

Wrapping Up

Working with archive logs in RDS for Oracle is all about knowing the right package calls and keeping retention tuned to match your actual usage patterns. The rdsadmin package covers most of what you'd normally do at the OS level, and once you're comfortable with it, day-to-day log management becomes straightforward.

The DMS scenario is where things tend to catch people off guard — usually when a task has been lagging for a while and logs quietly age out. Setting a sensible retention period upfront, and monitoring DMS lag regularly, goes a long way toward avoiding that headache.

Hope this helps if you're navigating similar issues. Happy to answer questions in the comments.