Skip to Main Content
  • Questions
  • ora-12954 on oracle xe 18c with less than 12gb user data

Breadcrumb

Question and Answer

Connor McDonald

Thanks for the question, Katharina.

Asked: March 25, 2020 - 8:43 am UTC

Last updated: September 13, 2021 - 1:58 am UTC

Version: Oracle database XE 18c

Viewed 10K+ times! This question is

You Asked

Dear Tom,

about two weeks ago we moved a test database from 12.2.0.1 SE2 to 18c XE via data pump. We used schema import into a pdb with compression enabled (from the parameter file: TRANSFORM=TABLE_COMPRESSION_CLAUSE:"ROW STORE COMPRESS ADVANCED"). There is no workload on this database yet and we set job_queue_processes=0, but we keep getting the following error about every 5 minutes:
Errors in file /opt/oracle/dbconfig/diag/rdbms/geltcdb/geltcdb/trace/geltcdb_smon_2651.trc:
ORA-00604: error occurred at recursive SQL level 1
ORA-12954: The request exceeds the maximum allowed database size of 12 GB.


The start of the tracefile says the following (the date given there is newer then "two weeks ago" because we recreated the database again, just to make sure everything was done right)
Trace file /opt/oracle/dbconfig/diag/rdbms/geltcdb/geltcdb/trace/geltcdb_smon_2651.trc
Oracle Database 18c Express Edition Release 18.0.0.0.0 - Production
Version 18.4.0.0.0
Build label:    RDBMS_18.4.0.0.0DBRU_LINUX.X64_181017
ORACLE_HOME:    /opt/oracle/product/18c/dbhomeXE
System name:    Linux
Node name:      geltst
Release:        5.3.4-1.el7.elrepo.x86_64
Version:        #1 SMP Sat Oct 5 10:27:41 EDT 2019
Machine:        x86_64
Instance name: geltcdb
Redo thread mounted by this instance: 1
Oracle process number: 23
Unix process pid: 2651, image: oracle@geltst (SMON)


*** 2020-03-21T00:02:59.557842+01:00 (CDB$ROOT(1))
*** SESSION ID:(565.64058) 2020-03-21T00:02:59.557893+01:00
*** CLIENT ID:() 2020-03-21T00:02:59.557903+01:00
*** SERVICE NAME:(SYS$BACKGROUND) 2020-03-21T00:02:59.557910+01:00
*** MODULE NAME:() 2020-03-21T00:02:59.557919+01:00
*** ACTION NAME:() 2020-03-21T00:02:59.557926+01:00
*** CLIENT DRIVER:() 2020-03-21T00:02:59.557934+01:00
*** CONTAINER ID:(1) 2020-03-21T00:02:59.557941+01:00

SMON: following errors trapped and ignored:
<error barrier> at 0x7fffc52ee1b0 placed ktm.c@3369
ORA-00604: error occurred at recursive SQL level 1
ORA-12954: The request exceeds the maximum allowed database size of 12 GB.

*** 2020-03-21T00:11:21.812361+01:00 (CDB$ROOT(1))
SMON: following errors trapped and ignored:
<error barrier> at 0x7fffc52ee1b0 placed ktm.c@3369
ORA-00604: error occurred at recursive SQL level 1
ORA-12954: The request exceeds the maximum allowed database size of 12 GB.


When we check for database size with this script: https://oracle-base.com/dba/script?category=monitoring&file=ts_free_space.sql
we get as result for cdb:
TABLESPACE_NAME                   SIZE_MB    FREE_MB MAX_SIZE_MB MAX_FREE_MB   FREE_PCT USED_PCT
------------------------------ ---------- ---------- ----------- ----------- ---------- -----------
SYSAUX                                570         34       32767       32231         98  ----------
SYSTEM                                840          9       32767       31936         97  ----------
UNDOTBS1                               45         36       32767       32758         99  ----------
USERS                                   5          4       32767       32766         99  ----------


and for the pdb (there's only one):
TABLESPACE_NAME                   SIZE_MB    FREE_MB MAX_SIZE_MB MAX_FREE_MB   FREE_PCT USED_PCT
------------------------------ ---------- ---------- ----------- ----------- ---------- -----------
GEL_DATA_1                           2548        311       32767       30530         93  X---------
GEL_INDX_1                           2300        126       32767       30593         93  X---------
GEL_ROLL_1                            500        499       32767       32766         99  ----------
LOGGER_LOGS_1                         500        499       32767       32766         99  ----------
SYSAUX                                460         28       32767       32335         98  ----------
SYSTEM                                280          9       32767       32496         99  ----------
UNDOTBS1                             8192       8168        8192        8168         99  ----------
USERS                                 190          9       32767       32586         99  ----------


So there should be still plenty of space for user data, shouldn't it?
We don't understand where this error comes from. What information can we get out of the trace file, by whom this error is generated? Do we have to worry about that, besides the fact that we frequently should purge alert log data and trace files? Right now we can insert data without problems.
Thank you for your time.

Katharina

and Connor said...

I suspect thats a bug in our reporting - as long as you can continue to create data, and your *user* data can grow to 12G then I would not be overly concerned.

However, I'll ask around internally and report back any findings.

Rating

  (1 rating)

Is this answer out of date? If it is, please let us know via a Comment

Comments

18c XE size limit

John Claxton, September 10, 2021 - 7:13 pm UTC

Bumped into this while doing some "hobbyist" work on an XE database.
Check your recyclebin - apparently it counts against you (as it probably should).
Connor McDonald
September 13, 2021 - 1:58 am UTC

Nice input.

More to Explore

Administration

Need more information on Administration? Check out the Administrators guide for the Oracle Database