If you’ve spent any meaningful time managing enterprise Oracle databases, you know the drill. LOB segments balloon over time. Fragmentation builds up. Storage costs creep upward. And somewhere on your to-do list — usually buried under more urgent fires — is a maintenance window you keep pushing back because shrinking a few hundred gigabytes of SecureFile LOBs isn’t exactly a quick job.
Oracle 23c doesn’t fix everything, but it takes direct aim at two of the more tedious recurring tasks in database storage management: SecureFile LOB cleanup and post-ingestion compression. Both are now largely automated. Here’s what that actually means in practice.
The SecureFile fragmentation problem, and why it’s been such a pain
SecureFiles are Oracle’s default architecture for large objects — documents, multimedia, anything unstructured. They work well, but they have a well-known long-term problem: as rows get updated and deleted over time, LOB segments accumulate dead space that doesn’t get reclaimed automatically. The data is gone, but the storage isn’t.
Before 23c, fixing this meant someone had to notice it was happening, run Segment Advisor, schedule a maintenance window, and execute something like:
ALTER TABLE sometable MODIFY LOB(column_name) SHRINK SPACE;In a small environment, that’s manageable. In a large enterprise environment with dozens of tables and terabytes of LOB data across multiple schemas, it becomes a recurring operational burden — the kind of task that’s easy to defer and expensive when you don’t.
What Automatic SecureFile Shrink actually does
In 23c, Oracle runs a background job every 30 minutes that identifies idle SecureFile LOB segments and reclaims unused space automatically — up to 5GB per segment per execution, done incrementally so it doesn’t hammer your I/O during business hours.
It works across the board: compressed LOBs, encrypted LOBs, deduplicated LOBs, standard SecureFiles. And because it runs in small incremental steps rather than one large operation, the performance impact is minimal — the kind of thing you’d barely notice in an AWR report.
If you’re on Oracle Autonomous Database in OCI, this is already on. For on-premises 23c, you enable it once:
BEGIN
DBMS_ADBTASK_ADMIN.ENABLE('AUTO_SF_SHRINK');
END;
/That’s it. After that, it just runs.
The practical impact is less about any single reclamation event and more about the cumulative effect over months. Fragmentation stops quietly compounding. Storage utilization stays cleaner without anyone having to actively manage it. And your maintenance window calendar gets a little less crowded.
The load performance vs. compression tradeoff — and how 23c resolves it
Compression is one of those things where the right answer has always been obvious in theory but awkward in practice. You want your data compressed for long-term storage efficiency. But compressing data during insertion adds overhead, and on high-throughput ingestion pipelines, that overhead matters.
The traditional workaround was to choose: fast loads or good compression. Some teams loaded uncompressed and ran compression jobs manually afterward. Others accepted slower loads to get the storage benefits upfront. Neither option was great.
Oracle 23c’s Automatic Storage Compression takes a different approach. Data loads uncompressed first — so ingestion performance stays fast — and then Oracle asynchronously converts it to Hybrid Columnar Compression in the background. You get the speed of uncompressed loads and the storage efficiency of HCC, without having to choose between them or schedule anything manually.
On top of that, Oracle applies intelligent clustering heuristics based on actual workload behavior — reorganizing data to improve how it aligns with your indexes, zone maps, and join zone maps. This isn’t static configuration; it adapts based on how your queries actually access the data.
Setting it up on-premises
For on-premises deployments, you’ll need a couple of prerequisites in place. First, Heat Map needs to be on — it’s how Oracle tracks access patterns to make intelligent compression decisions:
sql
ALTER SYSTEM SET heat_map=on SCOPE=BOTH;Then enable auto optimization:
EXEC DBMS_ILM_ADMIN.ENABLE_AUTO_OPTIMIZE;Your tables also need to be using Hybrid Columnar Compression, with tablespaces configured for Segment Space Management AUTO and autoallocation enabled. Again, on Autonomous Database this is all handled for you by default.
What this means for how DBAs spend their time
The honest framing here isn’t that these features are revolutionary — it’s that they remove a specific category of work that has always been necessary but never particularly valuable. Nobody goes into database engineering because they wanted to spend Friday afternoons reclaiming LOB space. These are housekeeping tasks that needed to happen, required expertise to do correctly, and consumed time that could have gone toward architecture decisions or performance tuning that actually moves the needle.
Automating them doesn’t change what databases fundamentally do. But it does shift where experienced DBAs spend their attention — which is genuinely useful as data volumes keep growing and the expectation of database self-management keeps rising.
If your organization is evaluating 23c adoption, storage alone probably isn’t the headline reason to move. But once you’re there, these two features will make the day-to-day considerably quieter — and that’s worth something.
