Oracle problems
ORA-00059: Maximum Number of DB_FILES Exceeded, and the Fix
3 November 2026
ORA-00059 arrives at the worst moment: a tablespace is full, the DBA adds a datafile, and Oracle refuses, because the database already has as many datafiles as DB_FILES allows. The parameter cannot be changed while the instance runs, so the only real fix is a restart, and the tablespace stays full until then. Nothing about it is sudden. The count climbs by one file at a time, for months, in plain sight in V$DATAFILE, and the query below shows how close it is.
What the limit is
Oracle's reference says DB_FILES specifies the maximum number of database files that can be opened for this database. The default is 200. It is not modifiable: a new value goes into the spfile and takes effect at the next startup, and in Oracle RAC every instance must have the same value. The minimum value is the largest absolute file number in the database, which is why the highest FILE# matters as much as the count. The control file has a limit of its own, MAXDATAFILES from CREATE CONTROLFILE, but that one takes care of itself: when a datafile is added above MAXDATAFILES but within DB_FILES, Oracle expands the control file automatically.
How close you are
SELECT (SELECT COUNT(*) FROM v$datafile) AS datafiles,
(SELECT MAX(file#) FROM v$datafile) AS highest_file#,
(SELECT TO_NUMBER(value) FROM v$parameter
WHERE name = 'db_files') AS db_files
FROM dual;
Compare the higher of the two figures with DB_FILES. The control file side, for completeness:
SELECT type, records_total, records_used
FROM v$controlfile_record_section
WHERE type = 'DATAFILE';
RECORDS_TOTAL is the MAXDATAFILES the control file was created with, and RECORDS_USED how many of the slots are taken. It grows on its own, so it is a figure to know, not a limit to manage.
How fast it climbs
SELECT TO_CHAR(creation_time, 'YYYY-MM') AS month, COUNT(*) AS added
FROM v$datafile
WHERE creation_time > ADD_MONTHS(SYSDATE, -12)
GROUP BY TO_CHAR(creation_time, 'YYYY-MM')
ORDER BY 1;
Twelve months of additions give the rate, and the rate gives the date the limit is reached. Three files a month against 40 left is a year; a migration that adds 30 tablespaces is next week.
Where the files come from
SELECT tablespace_name, COUNT(*) AS files,
ROUND(SUM(bytes)/1024/1024/1024) AS gb,
ROUND(SUM(maxbytes)/1024/1024/1024) AS max_gb
FROM dba_data_files
GROUP BY tablespace_name
ORDER BY files DESC;
The tablespace at the top of the list is almost always a smallfile tablespace that grew the only way a smallfile tablespace can. A datafile holds at most 4 million blocks, 32 GB at the usual 8 KB block size, so a 2 TB tablespace is at least 64 files, and every time it fills someone adds one more. The count that hits DB_FILES is that habit, multiplied by the years.
The fix, in order
- Raise DB_FILES, with room, and plan the restart.
ALTER SYSTEM SET db_files = 2000 SCOPE = SPFILEis the whole change; the ceiling is the operating system's, and the next change is another restart, so set a value for years rather than months. In RAC, set it for all instances and restart them all. - Until the restart, grow instead of adding. The error stops new files, not bigger ones.
ALTER DATABASE DATAFILE '...' RESIZEorAUTOEXTEND ON MAXSIZEon a file that has room under the 32 GB ceiling keeps the tablespace writable without a new file number. - Put new growth in bigfile tablespaces. A bigfile tablespace has one datafile, up to 4 billion blocks, and never adds a second, so its file count is one for good. A smallfile tablespace cannot be converted in place: the segments move to a new bigfile tablespace with
ALTER TABLE ... MOVEandALTER INDEX ... REBUILD, online on Enterprise Edition, or with Data Pump. - Stop the habit. Autoextend to the file's maximum first, a second file only when the first is at the ceiling, and a bigfile tablespace for anything that will pass a terabyte. The file count then follows the data, not the number of full-tablespace alerts.
- Check MAXDATAFILES only if you rebuild the control file. It expands automatically in normal operation; a
CREATE CONTROLFILEwritten by hand with a small value is the one way to bring it back as a limit.
See it coming
Radar Engine, the detection layer of Scops, counts the datafiles of every database each hour against its DB_FILES, forecasts the date the limit is reached from the rate at which files are added, and forecasts the space behind them, so the warning arrives when the fix is still a planned restart rather than a full tablespace that cannot be extended:
| Detector | Clock | When it fires |
|---|---|---|
| Datafiles near the limit | Hourly, against db_files. | 85%: Watch. Also full within 30 days: Warning. Under 3 left at 98%, or full within 2 days: Critical. |
| Datafile space running out | Daily forecast: datafiles to their maximum size, then ASM. | The date when ASM is full, against horizons of 14, 45 and 90 days. Else Watch. |
The finding names the database, the files in use against the limit, the rate and the date. Scops needs no agent on the server and no Diagnostics Pack for any of it, and the check runs on Standard Edition 2 as on Enterprise Edition.
Questions
What does ORA-00059 mean?
The database already has as many datafiles as the DB_FILES parameter allows, so a new datafile cannot be added. DB_FILES defaults to 200, and the fix is a higher value in the spfile and a restart of the instance.
Can I change DB_FILES without a restart?
No. The parameter is not modifiable while the instance runs; ALTER SYSTEM SET db_files SCOPE = SPFILE prepares the change and the next startup applies it. In Oracle RAC all instances must use the same value.
Do I also need to change MAXDATAFILES in the control file?
Usually not. When a datafile is added above MAXDATAFILES but within DB_FILES, Oracle expands the control file automatically. V$CONTROLFILE_RECORD_SECTION shows the slots in use for the DATAFILE type.
Why does my database have hundreds of datafiles?
Because a smallfile datafile holds at most 4 million blocks, 32 GB with an 8 KB block, and a large smallfile tablespace gets a new file every time it fills. Bigfile tablespaces hold one file of up to 4 billion blocks, and keep the count flat.
Related problems
Sources
- Oracle: DB_FILES, CREATE CONTROLFILE, V$CONTROLFILE_RECORD_SECTION, V$DATAFILE, Physical database limits
- Oracle: Managing tablespaces
- Scops docs: Detector reference