ODA Cleanup: Fix DCS-10803 and Clean /opt

I hit DCS-10803 due to low space on /opt, which required immediate ODA cleanup, right in the middle of a routine patching activity on Oracle Database Appliance.

The fix itself was straightforward—odacli cleanup-patchrepo. But what made this interesting was not the command. It was understanding what actually consumes space, what is safe to clean, and how ODA cleanup really works in practice. In this post, I explain how /opt is structured on ODA and how different utilities help manage its cleanup and maintenance.

ODA Cleanup: DCS-10803 and /opt Space Issues

Below is the failure message and when i looked at the utilization

DCS-10803: Insufficient disk space on file system: /opt
Expected free space: 3.63 GB, available space: 2.91 GB

Filesystem                         Size  Used Avail Use% Mounted on
/dev/mapper/VolGroupSys-LogVolOpt   32G   27G  3.2G  90% /opt

What Does /opt Store on ODA?

On the surface, /opt behaves like any Linux system—it contains tools, configuration files, and logs. On ODA, however, it stores additional files. It stores DCS logs and trace files, acts as a repository for patch bundles (OS, AHF, firmware, etc.), and serves as a staging area for database and Grid Infrastructure software.

However, NOT everything under /opt/oracle actually consumes space from /opt.

As seen below there are 2 sub directories of /opt, that are mounted separately as ACFS volume. This means that files under these sub directories DO NOT contribute to the disk space utilization of /opt, i.e.

• /opt (LogVolOpt) → consume space on /opt
• /opt/oracle/dcs/commonstore → separate ACFS mount
• /opt/oracle/oak/pkgrepos/orapkgs/clones → separate ACFS mount

An interesting sub directory is pkgrepos, this contains OS patches, AHF bundles, DCS components, firmware updates, and DB/GI clones. Every time a new version is staged, its contents are added here—however older versions are not automatically removed. Over time, multiple versions accumulate and fill up space.

/dev/mapper/VolGroupSys-LogVolOpt    59G   47G  9.2G  84% /opt
/dev/asm/commonstore-157             5.0G  672M  4.4G  14% /opt/oracle/dcs/commonstore
/dev/asm/acfsclone-157              150G   42G  109G  28% /opt/oracle/oak/pkgrepos/orapkgs/clones

## A look under pkgrepos

/opt/oracle/oak/pkgrepos/
└── orapkgs/
    ├── os/        # OS patch repository (patch bundles, patch metadata)
    ├── ahf/        # AHF patch repository (patch bundles, patch metadata)
 .... 
.....
....
    ├── clones/    # Gold images (ACFS mount - NOT using /opt) >>>>>>>>

ODA Cleanup Using odacli cleanup-patchrepo

The odacli clean-patchrepo & oakcli manage cleanrepo commands are designed to safely remove unused repository content. They can be used to clean up the older staged versions of the patches as well as the clone files.

By default, the command only cleans DB and GI components. That leaves behind OS, AHF, firmware, and other patch bundles—which still consume /opt. Hence it is imp to use -comp all

## Cleanup patches for All comonponets (DCS, AHF, ILOM..)
## Default for -comp is

odacli cleanup-patchrepo -comp all

When cleaning up the patch repository using odacli cleanup-patchrepo, it is important to note that not all content can be removed. By design, the command cannot delete versions recommended to be retained for system recoverability (base and current/active version)

Clone Files

The -cl option removes old gold images. However, since clones are stored on a separate ACFS mount, this does not free /opt space. It is still good housekeeping.

## Cleanup clone files for All comonponets (DB,GI)
 
odacli cleanup-patchrepo -cl -comp all -v 19.23.0.0.0
{
  "jobId" : "3ba99a65-2e91-413d-a993-5140797a525a",
  "status" : "Created",
  "message" : "",
  "reports" : [ ],
  "createTimestamp" : "October 10, 2025 16:54:41 UTC",
  "resourceList" : [ ],
  "description" : "Cleanup patchrepos",
  "updatedtime" : "October 10, 2025 16:54:41 UTC",
  "jobType" : null,
  "cpsMetadata" : null
}

ODA Cleanup: Managing Logs Under /opt

After cleaning the repository, there is another area that needs attention—logs. As we have observed the DCS logs, in particular, are stored under /opt. Over time, they can contribute significantly to space usage, hence in order to cleanup the DCS logs we can use the purge job utility.

You can use the odacli list-logspaceusage to review the space utilization. You will notice that this command lists the utilization of directories across LovVolOpt (/opt) and LogVolU01 (/u01)

## Log files and locations of typical dcs logs & trace files

/opt/oracle/dcs/log/dcs-agent.log
/opt/oracle/dcs/dcscli/log/dcscli.log
/opt/oracle/dcs/log/jobfiles/<jobId>/

odacli list-logspaceusage

Timestamp: April 15, 2025 10:06:40 AM EDT
----------------------------------------------------------------
Component Size(MB) Partition LogUsagePercentage PartitionFreePercentage
-------------------- -------------------- -------------------- -------------------- --------------------
dcs 2267.00 /dev/mapper/VolGroupSys-LogVolOpt 3.76 9.00
gi 13383.68 /dev/mapper/VolGroupSys-LogVolU01 6.64 48.00
database 3153.92 /dev/mapper/VolGroupSys-LogVolU01 1.57 48.00

Instead of manually deleting logs, ODA provides built-in utilities to manage them. You can check if Log Cleanup Job Already Exists if not setup using the odcali commands listed below. More details about this can be found in KB118547 (Doc ID 2081655.1)

## List logspace Utilizaiton 
odacli list-logspaceusage

## Review log cleanup jobs 

odacli list-logcleanjobs 
odacli list-auto-logclean-policy 
odacli describe-logcleanjob 

## Create 
odacli create-auto-logclean-policy 
odacli create-logcleanjob -c DCS -o 7 -u Day

Of course, starting with ODA 19.27, the LogVolOpt (/opt) volume can be extended to increase available space. However, before taking that step, it’s important to ensure that proper ODA cleanup is already in place. In most cases, cleaning up unused repository content and managing log growth will resolve the issue without needing additional storage.