This post is also available in:
A new CDB creation via DBCA silent mode hangs at 42% running catalog.sql. The catalog0.log file is zero bytes, catcon reports a credential validation failure, but the database connection itself works fine. The real culprit lives somewhere nobody thinks to look: glogin.sql.
This post walks through the full investigation, the root cause backed by official Oracle documentation, and three solution paths (safest to most aggressive).
Tested environment: Oracle Database 19c Enterprise Edition 19.29.0.0.0, Oracle Linux, Oracle Restart (HAS), ASM (+DATA / +ARCH).
The Error
The scenario is a lean CDB creation through DBCA silent mode, using the New_Database.dbt template (the only one that lets you build a database without optional components like JVM, Text, Spatial, OLAP, Multimedia). The goal is a minimal target database for a Data Pump import from a 12.2.0.1 source.
Response file in use:
responseFileVersion=/oracle/assistants/rspfmt_dbca_response_schema_v19.0.0
gdbName=c19db4
sid=c19db4
databaseConfigType=CDB
createAsContainerDatabase=true
numberOfPDBs=1
pdbName=HPIX
useLocalUndoForPDBs=true
templateName=General_Purpose.dbc
sysPassword=<PASSWORD>
systemPassword=<PASSWORD>
pdbAdminPassword=<PASSWORD>
storageType=ASM
diskGroupName=+DATA
recoveryAreaDestination=+ARCH
characterSet=WE8ISO8859P1
nationalCharacterSet=AL16UTF16
listeners=LISTENER
automaticMemoryManagement=false
memoryPercentage=0
initParams=sga_target=50G,pga_aggregate_target=50G,processes=1500Command:
$ORACLE_HOME/bin/dbca -silent -createDatabase \
-responseFile /tmp/c19db4.rsp \
-templateName New_Database.dbt \
-dbOptions JSERVER:false,DV:false,OMS:false,SPATIAL:false,IMEDIA:false,ORACLE_TEXT:false,CWMLITE:false,OLS:false \
-J-Doracle.assistants.dbca.validate_changes=false \
| tee /tmp/dbca_c19db4.logCreation progresses normally until 42% and dies:
Prepare for db operation
6% complete
Registering database with Oracle Restart
10% complete
Creating and starting Oracle instance
12% complete
16% complete
Creating database files
17% complete
23% complete
Creating data dictionary views
25% complete
42% complete
100% complete
[FATAL] Error while executing "/u01/app/oracle/product/19.0.0/db_1/rdbms/admin/catalog.sql".
Refer to "/u01/app/oracle/cfgtoollogs/dbca/c19db4/catalog0.log" for more details.
Error in Process: /u01/app/oracle/product/19.0.0/db_1/perl/bin/perlThe catalog0.log file is 0 bytes. The script never executed at all.
💡 In the field
This scenario shows up exactly when you want a lean database for a migration. The General_Purpose.dbc template ships everything by default, and stripping components later is painful. The right path is New_Database.dbt, and that is precisely where this bug bites.
The behavior is misleading: DBCA prints 100% complete right before [FATAL], which suggests something finished. Nothing finished. The progress bar jumped straight to 100% because the next step (running catalog.sql) aborted immediately.
Worse, catcon reports unexpected error in validate_credentials, which sends any DBA chasing the password file, sqlnet.ora, OS authentication, OPatch inventory. None of those leads to the real cause.
Diagnosis
Clue 1: catcon fails before running anything
The catcon log (catalog_catcon_XXXXXX.lst) shows:
catcon::catconInit2: finished constructing connect strings
catcon::catconInit2: unexpected error in validate_credentials
Unexpected error encountered in catconInit2; exiting
Enter Password:
Enter Password:Looks like authentication. It is not. catcon uses / as sysdba and connects successfully to the instance (Connected. appears in the detailed log).
Clue 2: sqlplus connects, then dies immediately
Inside the detailed .lst:
line does not match marker: Connected.
line does not match marker: ERROR:
line does not match marker: ORA-06553: PLS-213: package STANDARD not accessiblesqlplus connects and immediately hits ORA-06553, before catcon ever runs a single query from catalog.sql. catcon misreads that error as a credential failure and aborts. catalog.sql never ran.
Clue 3: why does the error fire before any query?
A database freshly built with New_Database.dbt has no data dictionary. The STANDARD package is one of the first objects created by catalog.sql / catproc.sql. Any PL/SQL call in that state returns ORA-06553.
But catcon only runs a plain SELECT status FROM v$instance, which is pure SQL. So why the error?
Because something runs before catcon issues any query: glogin.sql.
Root Cause
According to the official Oracle 19c documentation (SQLPlus User’s Guide and Reference, Chapter 2: Configuring SQLPlus), the file $ORACLE_HOME/sqlplus/admin/glogin.sql is the Site Profile and runs automatically on every successful SQL*Plus connection, including the internal CONNECT chain that catcon performs.
In this environment, the glogin had been customized:
set pagesize 200
set linesize 190
define _editor=gvim
set serveroutput on
define gname=idle
column global_name new_value gname
set heading off
set termout off
set feedback off
col global_name noprint
select upper(sys_context ('userenv', 'con_name') || '@' ||
sys_context('userenv', 'instance_name')) global_name from dual;
set sqlprompt '&gname> '
ALTER SESSION SET NLS_DATE_FORMAT='DD-MM-YYYY HH24:MI:SS';
ALTER SESSION SET NLS_TIMESTAMP_FORMAT='DD-MM-YYYY HH24:MI:SS.FF';
set heading on
set termout on
set feedback onTwo lines are fatal in a database with no data dictionary:
set serveroutput oninternally callsDBMS_OUTPUT.ENABLE, which is PL/SQL and depends on theSTANDARDpackage. NoSTANDARD,ORA-06553.select upper(sys_context(...))drags in function and type resolution that also leans onSTANDARDduring parse and execution.
Both fail with ORA-06553 before catcon ever sends a command to catalog.sql. catcon sees an error right after Connected. and bails.
Why does it work with General_Purpose.dbc?
The two templates are not equivalent:
General_Purpose.dbcis seed-based. It ships prebuilt binary datafiles where the catalog is already installed. DBCA copies those files and the database is born withSTANDARDalready in place. The glogin runs fine.New_Database.dbtis structure-only. It builds everything from scratch through scripts (catalog.sql,catproc.sql, and friends). The database starts empty and needs those scripts to run, but catcon connects via sqlplus first, the glogin fires, PL/SQL fails, andcatalog.sqlnever gets its turn.
This behavior is the basis for MOS Doc ID 3091458.1 (catalog.sql getting ORA-06553: PLS-213: Package STANDARD Not Accessible) and MOS Doc ID 400942.1 (Create Database Statement Generates Error ORA-06553).
Solutions
Three paths, safest to most aggressive. Pick by context.
Solution 1: resilient glogin.sql (recommended for shared ORACLE_HOME)
⚠️ Use this approach if the ORACLE_HOME hosts other production databases. Renaming the glogin affects every sqlplus connection on the host, including monitoring scripts and cron jobs.
Make the glogin immune to databases without a catalog. Drop set serveroutput on and wrap PL/SQL-flavored calls with WHENEVER SQLERROR CONTINUE:
-- Resilient glogin.sql for new database creation
set pagesize 200
set linesize 190
define _editor=gvim
define gname=idle
column global_name new_value gname
set heading off
set termout off
set feedback off
col global_name noprint
-- Guard against ORA-06553 on databases without a data dictionary
WHENEVER SQLERROR CONTINUE
select upper(sys_context ('userenv', 'con_name') || '@' ||
sys_context('userenv', 'instance_name')) global_name from dual;
set sqlprompt '&gname> '
WHENEVER SQLERROR EXIT SQL.SQLCODE
ALTER SESSION SET NLS_DATE_FORMAT='DD-MM-YYYY HH24:MI:SS';
ALTER SESSION SET NLS_TIMESTAMP_FORMAT='DD-MM-YYYY HH24:MI:SS.FF';
set heading on
set termout on
set feedback on
-- DO NOT use "set serveroutput on" here. It is implicit PL/SQL.This version works in any database state (catalog present, missing, in upgrade) and keeps the cosmetic settings you want.
Solution 2: rename glogin temporarily
⚠️ Heads up: while the glogin is renamed, every other DBA, job, or script on the host connecting through sqlplus loses your customizations (NLS, prompt). Tell the team before doing this.
If the ORACLE_HOME is dedicated to this new database, just move the glogin out of the way during creation:
mv $ORACLE_HOME/sqlplus/admin/glogin.sql \
$ORACLE_HOME/sqlplus/admin/glogin.sql.bkp
$ORACLE_HOME/bin/dbca -silent -createDatabase \
-responseFile /tmp/c19db4.rsp \
-templateName New_Database.dbt \
-dbOptions JSERVER:false,DV:false,OMS:false,SPATIAL:false,IMEDIA:false,ORACLE_TEXT:false,CWMLITE:false,OLS:false \
-J-Doracle.assistants.dbca.validate_changes=false \
| tee /tmp/dbca_c19db4.log
mv $ORACLE_HOME/sqlplus/admin/glogin.sql.bkp \
$ORACLE_HOME/sqlplus/admin/glogin.sqlSolution 3: use General_Purpose.dbc and strip components afterwards
If you do not need a lean database from day one, use the seed-based template and remove components later through the official catnoXXX.sql scripts. Not elegant, but DBCA will not fail.
⚠️ Cost of this path: the database is born with JVM, XDB, Text, Spatial, etc. Each removal needs downtime and the matching official script (
catnojav.sql,catnoxdb.sql, and so on). For a database that will receive Data Pump with clean schemas, Solution 1 or 2 is better.
Quick checklist
cp $ORACLE_HOME/sqlplus/admin/glogin.sql{,.bkp}
grep -E 'serveroutput|exec |begin |dbms_' $ORACLE_HOME/sqlplus/admin/glogin.sql
$ORACLE_HOME/bin/dbca -silent -createDatabase \
-responseFile /tmp/c19db4.rsp \
-templateName New_Database.dbt \
-dbOptions JSERVER:false,DV:false,OMS:false,SPATIAL:false,IMEDIA:false,ORACLE_TEXT:false,CWMLITE:false,OLS:false \
-J-Doracle.assistants.dbca.validate_changes=false
sqlplus / as sysdba
SQL> select comp_id, comp_name, status from dba_registry;Expected output on a New_Database.dbt build with dbOptions all-false:
COMP_ID COMP_NAME STATUS
----------- ----------------------------------------- -----------
CATALOG Oracle Database Catalog Views VALID
CATPROC Oracle Database Packages and Types VALID
OWM Oracle Workspace Manager VALID
RAC Oracle Real Application Clusters OPTION OFF
XDB Oracle XML Database VALIDFive entries. Zero optional components. Exactly the goal.
Takeaways
✅ glogin.sql is invisible but runs everywhere. Every sqlplus connection on the host (catcon, AutoUpgrade, datapatch, your own scripts) goes through it. A glogin that smuggles in implicit PL/SQL silently breaks critical operations.
✅ The dbOptions flag only matters with New_Database.dbt. General_Purpose.dbc ignores dbOptions because the components are baked into the seed datafiles.
✅ Pass dbOptions on the command line, not in the response file. Command-line values are more reliable and template-independent.
✅ The unexpected error in validate_credentials message is a red herring. It has nothing to do with authentication. Whenever it shows up during database creation, open the detailed .lst and look for ORA- right after Connected..
✅ Never put set serveroutput on in glogin.sql. It is implicit PL/SQL. Use it in the user-level login.sql if you really need it.
References
- Oracle Database 19c SQLPlus User’s Guide and Reference, Chapter 2: Configuring SQLPlus
- MOS Doc ID 3091458.1: catalog.sql getting ORA-06553: PLS-213: Package STANDARD Not Accessible
- MOS Doc ID 400942.1: Create Database Statement Generates Error ORA-06553 PLS-213 Package Standard Not Accessible
- Oracle Database 19c Administrator’s Guide: Creating and Configuring an Oracle Database
Tested on: Oracle Database 19c Enterprise Edition Release 19.29.0.0.0, Oracle Linux, Oracle Restart (HAS), ASM (+DATA / +ARCH).
