Oracle problems

ORA-01536: Space Quota Exceeded for Tablespace, and the Fix

3 November 2026

ORA-01536 is the full-tablespace error with a twist: the tablespace has room, and the user does not. Oracle's reference puts it in one sentence: the space quota for the segment owner in the tablespace has been exhausted and the operation attempted the creation of a new segment extent in the tablespace. The quota belongs to the owner of the table or index, not to the session that inserted, which is why an application account with a perfectly good quota still gets the error when the table it fills belongs to another schema. One query shows every quota and how full it is, and the fix is one ALTER USER, sized from the data instead of guessed.

Every quota, and how full it is

SELECT username, tablespace_name,
       ROUND(bytes/1024/1024) AS used_mb,
       CASE WHEN max_bytes = -1 THEN NULL
            ELSE ROUND(max_bytes/1024/1024) END AS quota_mb,
       CASE WHEN max_bytes = -1 THEN NULL
            ELSE ROUND(100 * bytes / max_bytes) END AS pct
FROM   dba_ts_quotas
WHERE  dropped = 'NO'
ORDER  BY pct DESC NULLS LAST;

Oracle's reference describes DBA_TS_QUOTAS as the tablespace quotas for all users: BYTES is the number of bytes charged to the user, MAX_BYTES the user's quota in bytes, or -1 if no limit, and DROPPED whether the tablespace has been dropped. A row at 100 percent is the error; a row at 90 is next week. The users that are not in the view for a tablespace either own nothing in it or hold the system privilege that bypasses quotas altogether:

SELECT grantee
FROM   dba_sys_privs
WHERE  privilege = 'UNLIMITED TABLESPACE'
ORDER  BY grantee;

Who owns the space in the tablespace

SELECT s.owner, ROUND(SUM(s.bytes)/1024/1024) AS mb,
       COUNT(*)                                AS segments,
       MAX(q.max_bytes)                        AS quota_bytes
FROM   dba_segments s
LEFT   JOIN dba_ts_quotas q
       ON  q.username = s.owner
       AND q.tablespace_name = s.tablespace_name
WHERE  s.tablespace_name = '&tablespace'
GROUP  BY s.owner
ORDER  BY mb DESC;

The owner at the top with a quota is the one that will hit it; an owner with no quota row and no UNLIMITED TABLESPACE cannot create a segment there at all, which is the other face of the same error on the first insert into a new table.

The fix, in order

1. Raise the quota, for the owner, from the data. ALTER USER app_owner QUOTA 50G ON app_data, where 50 GB is the current use plus the growth of the next year, not a round number. QUOTA UNLIMITED ON app_data removes the limit on that one tablespace and nowhere else. Oracle's own action for the error is this, or dropping unnecessary objects in the tablespace.
2. Count the recycle bin. A dropped table keeps its space, and its charge against the owner's quota, until the recycle bin is purged; PURGE RECYCLEBIN as the owner, or PURGE DBA_RECYCLEBIN, often ends the error without a new quota.
3. Keep quotas where they guard something. A quota on a shared tablespace keeps one runaway load from taking the space of every other schema in it, and that is the place for one. An owner with its own tablespace needs no quota, because the tablespace is the limit; UNLIMITED TABLESPACE as a system privilege belongs to nobody but the DBA accounts, since it ignores every quota on every tablespace, SYSTEM included.
4. Check the tablespace itself. The quota is the first limit; the tablespace is the second, and a quota raised to more than the tablespace can give only changes which error arrives.
5. Set the quota at creation. CREATE USER ... QUOTA ... ON for every application owner, so the limit is a decision and not a default.

See it coming

Radar Engine, the detection layer of Scops, reads every quota of every database each hour, with the rate at which the owner's segments grow, so a quota that will be full on Thursday is a finding on Monday, with the owner, the tablespace and the figure to set:

The finding names the owner, the tablespace, the quota, the use and the day it runs out. Scops reads it through a 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-01536 mean?
The owner of the segment has used up its quota on the tablespace and a new extent could not be created, even though the tablespace itself may have free space. The fix is a larger quota for that owner, ALTER USER ... QUOTA ... ON tablespace, or space freed by dropping or purging objects.

Why do I get ORA-01536 when the tablespace is not full?
Because a quota is a limit per user per tablespace. DBA_TS_QUOTAS shows BYTES charged against MAX_BYTES for each owner; the tablespace's own free space is a separate limit.

Whose quota counts, the session's or the table owner's?
The segment owner's. An application account that inserts into a table owned by another schema is charged against that schema's quota, which is why the account's own quota does not help.

Does the recycle bin count against the quota?
Yes. A dropped table keeps its space and its charge against the owner until the recycle bin is purged, so PURGE RECYCLEBIN is often the whole fix.

Related problems

• Tablespace full: ORA-01653
• ORA-65114: PDB storage limit reached
• The database is growing fast
• All Oracle problems

Sources

• Oracle: DBA_TS_QUOTAS, CREATE USER, ALTER USER, ORA-01536
• Oracle: Managing tables, the recycle bin
• Scops docs: Detector reference