Space consumption climbs steadily and the usual housekeeping appears to be scheduled.
Most likely causes
- The purge is scheduled but erroring on every run. A failing recurring job can look identical to a healthy one in a schedule list.
- The retention parameter keeps everything. A purge configured with a long or open-ended retention runs successfully and deletes nothing.
- Rows are deleted and the segment does not shrink. Deleting rows frees space inside the segment for reuse, not back to the tablespace.
- The growth is somewhere else entirely. Audit, interface and log tables often grow faster than the transactional ones being purged.
What to check
- The last several runs of the purge and their completion status — not merely that a schedule exists.
- The retention parameters actually in use.
- Which segments are largest and which have grown most, rather than assuming.
- Whether the growth is in tables, indexes, or undo and temporary space.
If none of the above explains it, raise a ticket and include what you checked. Reading this article cost you no hours.