Scops
Docs Download

Oracle problems

ORA-65114: PDB Storage Limit Reached, and the Fix

3 November 2026

ORA-65114 is a tablespace-full error for a whole pluggable database: someone set a storage limit on the PDB with STORAGE (MAXSIZE ...), usually when it was created on a shared container, and its datafiles and tempfiles have grown to it. Every tablespace in the PDB may have free space, autoextend may be on, the disk may be half empty, and the PDB still cannot grow, because Oracle's multitenant guide says the limit applies to the total size of all data files and temp files comprising tablespaces that belong to the PDB. One query shows every PDB against its limit, and the fix is one statement in the root, or a datafile shrink that gives the budget back without touching the limit.

Every PDB against its limit

SELECT con_id, name, open_mode,
       ROUND(total_size/1024/1024/1024, 1) AS used_gb,
       ROUND(max_size/1024/1024/1024, 1)   AS max_gb,
       CASE WHEN max_size > 0
            THEN ROUND(100 * total_size / max_size) END AS pct
FROM   v$pdbs
ORDER  BY pct DESC NULLS LAST;

Oracle's reference describes TOTAL_SIZE in V$PDBS as the disk space used by the PDB, including both data and temp files, and MAX_SIZE as the maximum amount of disk space that can be used by data and temp files in the PDB. A PDB without a limit shows no percentage. The same limit is visible from inside the PDB as a database property:

SELECT con_id, property_name, property_value
FROM   cdb_properties
WHERE  property_name IN ('MAX_PDB_STORAGE', 'MAX_SHARED_TEMP_SIZE')
ORDER  BY con_id;

What takes the budget

SELECT tablespace_name,
       ROUND(SUM(bytes)/1024/1024/1024, 1)    AS file_gb,
       ROUND(SUM(maxbytes)/1024/1024/1024, 1) AS autoextend_to_gb,
       COUNT(*)                               AS files
FROM   cdb_data_files
WHERE  con_id = &con_id
GROUP  BY tablespace_name
ORDER  BY file_gb DESC;

The limit counts file size, not used space. A datafile of 50 GB with 10 GB of data in it charges 50 GB against the PDB's limit, which makes the next query the one that finds the cheap fix: the tablespaces whose files are much bigger than their contents.

SELECT m.tablespace_name,
       ROUND(m.used_space*t.block_size/1024/1024/1024, 1) AS used_gb,
       ROUND(m.used_percent, 1)                            AS pct
FROM   dba_tablespace_usage_metrics m
JOIN   dba_tablespaces t ON t.tablespace_name = m.tablespace_name
ORDER  BY used_gb DESC;

Run inside the PDB. USED_SPACE is, in Oracle's words, the total space consumed by all objects created in the tablespace; against FILE_GB from the query before it, the difference is file space the PDB is paying for and not using.

The fix, in order

  1. Raise the limit, from the root. ALTER PLUGGABLE DATABASE pdb2 STORAGE (MAXSIZE 500G); Oracle's reference says the value must be greater than or equal to the combined size of the existing tablespaces belonging to the PDB, otherwise an error occurs. STORAGE (MAXSIZE UNLIMITED) removes the limit on the tablespaces, and STORAGE UNLIMITED removes it on the shared temporary tablespace as well.
  2. Give back file space instead. A datafile that is mostly empty is shrunk with ALTER DATABASE DATAFILE '...' RESIZE down to its high-water mark, and a tempfile that grew for one sort last year is shrunk the same way or dropped and recreated small. The PDB's use falls by the difference, with the limit unchanged.
  3. Move the old rows out. The tables that grow are the ones with history nobody queries; archiving them moves the rows out online and leaves the limit for the data that is used.
  4. Set the limit on purpose. A limit per PDB on a shared container protects the other PDBs from one that runs away, and that is a good reason for one. Size it from the growth, and keep the forecast in view, so the limit is raised a week before it is hit and not at three in the morning.
  5. Mind the shared temp. The guide says the clause can also limit the storage in a shared temporary tablespace that sessions connected to the PDB may use, and when that limit is reached no additional storage in the shared temporary tablespace is available to them; a sort that fails inside one PDB only may be this limit, not the tablespace.

See it coming

Radar Engine, the detection layer of Scops, forecasts the storage of every PDB against its limit each hour, the same way it forecasts a tablespace, so the day the limit is reached is a finding weeks before, with the PDB, the limit, the use and the date:

DetectorClockWhen it fires
PDB storage filling upHourly forecast against MAX_PDB_STORAGE.As for a tablespace: the date it fills, against horizons of 14, 45 and 90 days.
Tablespace filling upHourly forecast, above 30% of the maximum size, after three days of readings.The date it fills, against horizons of 14, 45 and 90 days.

Scops watches the container and every PDB in it through one read-only account, with nothing installed in the database and no Diagnostics Pack, on Standard Edition 2 as on Enterprise Edition.

Questions

What does ORA-65114 mean?
The pluggable database has reached the storage limit set with STORAGE (MAXSIZE ...), which caps the total size of its datafiles and tempfiles. Free space inside the tablespaces does not help; the fix is a higher limit from the root, or smaller files.

How do I see a PDB's storage limit?
V$PDBS shows TOTAL_SIZE against MAX_SIZE for every PDB from the root, and inside the PDB the MAX_PDB_STORAGE property in DATABASE_PROPERTIES holds the same limit.

Does empty space in a datafile count against the limit?
Yes. The limit applies to the size of the files, so a datafile that is mostly empty charges its full size. Shrinking it with ALTER DATABASE DATAFILE ... RESIZE gives that space back to the PDB without changing the limit.

How do I remove the limit?
From the root: ALTER PLUGGABLE DATABASE pdb STORAGE (MAXSIZE UNLIMITED) for the tablespaces, or STORAGE UNLIMITED for the tablespaces and the shared temporary tablespace together.

Related problems

Sources