Close Menu
Oracle

ORA-06553: DBCA Falha no catalog.sql com PLS-213

HenriqueBy Updated:10 Mins Read

This post is also available in: English (Inglês)

A criação de um novo CDB via DBCA silent mode trava em 42% executando catalog.sql. O arquivo catalog0.log tem zero bytes, o catcon reporta falha de validação de credenciais, mas a conexão com o banco funciona perfeitamente. A causa real está num lugar que ninguém investiga: o glogin.sql.

Este post mostra a investigação completa, a causa raiz validada na documentação oficial Oracle, e três caminhos de solução (do mais seguro ao mais agressivo).

Ambiente testado: Oracle Database 19c Enterprise Edition 19.29.0.0.0, Oracle Linux, Oracle Restart (HAS), ASM (+DATA / +ARCH).

O Erro

O cenário é a criação de um CDB enxuto via DBCA silent mode, usando o template New_Database.dbt (único que permite criar um banco sem componentes opcionais como JVM, Text, Spatial, OLAP, Multimedia). O objetivo é um banco mínimo para receber Data Pump de um 12.2.0.1.

Response file usado:

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=<SENHA>
systemPassword=<SENHA>
pdbAdminPassword=<SENHA>
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=1500

Comando de execução:

$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

A criação avança normalmente até 42% e morre:

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/perl

O catalog0.log está com 0 bytes. O script sequer chegou a executar.

💡 Na prática

Esse cenário aparece exatamente quando você quer um banco enxuto para uma migração. O template General_Purpose.dbc cria banco com tudo, e remover componentes depois é dor de cabeça. O caminho correto é o New_Database.dbt, e é justamente nele que esse bug aparece.

O comportamento engana: o DBCA mostra “100% complete” antes do [FATAL], o que sugere que algo terminou. Não terminou. A barra de progresso pulou direto para 100% porque a próxima etapa (executar catalog.sql) abortou imediatamente.

Pior: o catcon reporta unexpected error in validate_credentials, o que leva qualquer DBA a investigar password file, sqlnet.ora, OS authentication, OPATCH. Nenhuma dessas pistas leva à causa real.

Diagnóstico

Pista 1: o catcon falha antes de rodar qualquer coisa

O log do catcon (catalog_catcon_XXXXXX.lst) mostra:

catcon::catconInit2: finished constructing connect strings
catcon::catconInit2: unexpected error in validate_credentials
Unexpected error encountered in catconInit2; exiting
Enter Password:
Enter Password:

Parece autenticação. Mas o catcon usa / as sysdba e conecta com sucesso na instância (Connected. aparece em outro log).

Pista 2: o sqlplus conecta, mas morre imediatamente

Dentro do .lst detalhado:

line does not match marker: Connected.
line does not match marker: ERROR:
line does not match marker: ORA-06553: PLS-213: package STANDARD not accessible

O sqlplus conecta e na sequência recebe ORA-06553, antes de executar qualquer query do catalog.sql. O catcon interpreta o erro como falha de credencial e aborta. O catalog.sql nunca chega a rodar.

Pista 3: por que o erro aparece antes de qualquer query?

Um banco recém-criado com New_Database.dbt não tem catálogo. O package STANDARD é um dos primeiros objetos criados pelo catalog.sql / catproc.sql. Qualquer tentativa de executar PL/SQL nesse estado resulta em ORA-06553.

Mas o catcon faz um simples SELECT status FROM v$instance, que é SQL puro. Então por que o erro?

Porque existe algo que executa antes de qualquer query do catcon: o glogin.sql.

Por que acontece

Conforme a documentação oficial do SQLPlus 19c (SQLPlus User’s Guide and Reference, Chapter 2: Configuring SQLPlus), o arquivo $ORACLE_HOME/sqlplus/admin/glogin.sql é o Site Profile e é executado automaticamente em toda conexão SQLPlus bem-sucedida, incluindo a sequência de CONNECT interna do catcon.

No ambiente em questão, o glogin estava customizado:

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 on

Duas linhas são fatais num banco sem catálogo:

  • set serveroutput on internamente chama DBMS_OUTPUT.ENABLE, que é PL/SQL e depende do package STANDARD. Sem STANDARD, ORA-06553.
  • select upper(sys_context(...)) envolve resolução de função e tipos que também recorrem ao STANDARD durante o parse / execução.

Ambas falham com ORA-06553 antes do catcon enviar qualquer comando ao catalog.sql. O catcon ve um erro logo após Connected. e aborta.

Por que funciona com General_Purpose.dbc?

Os dois templates não são iguais:

  • General_Purpose.dbc é seed-based. Contém datafiles binários pré-construídos onde o catálogo já está instalado. O DBCA copia esses datafiles e o banco nasce com o STANDARD package já disponível. O glogin funciona normalmente.
  • New_Database.dbt é structure-only. Cria tudo do zero via scripts (catalog.sql, catproc.sql, etc). O banco nasce sem catálogo e precisa rodar esses scripts, mas o catcon conecta via sqlplus, o glogin dispara, e o PL/SQL falha antes do catalog ter chance de rodar.

Esse comportamento é a base do MOS Doc ID 3091458.1 (catalog.sql getting ORA-06553: PLS-213: Package STANDARD Not Accessible) e do MOS Doc ID 400942.1 (Create Database Statement Generates Error ORA-06553).

Solução

Três caminhos, do mais seguro ao mais agressivo. Escolha conforme o cenário.

Solução 1: glogin.sql resiliente (recomendado para ORACLE_HOME compartilhado)

⚠️ Use esta abordagem se o ORACLE_HOME hospeda outros bancos em produção. Renomear o glogin afeta toda conexão sqlplus do host, incluindo scripts de monitoração e jobs do cron.

Torne o glogin imune a bancos sem catálogo. Remova set serveroutput on e proteja chamadas PL/SQL com WHENEVER SQLERROR CONTINUE:

-- glogin.sql resiliente para criação de bancos novos
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

-- Protege contra ORA-06553 em bancos sem catálogo
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

-- NÃO use "set serveroutput on" aqui. É PL/SQL implícito.

Essa versão funciona em qualquer estado do banco (catálogo presente, ausente, em upgrade) e mantém os efeitos visuais que você quer.

Solução 2: renomear o glogin temporariamente

⚠️ Atenção: durante o intervalo em que o glogin estiver renomeado, qualquer outro DBA / job / script que conectar via sqlplus no host perde as customizações (NLS, prompt). Aviso a equipe antes.

Se o ORACLE_HOME é dedicado a este banco novo, basta tirar o glogin do caminho durante a criação:

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.sql

Solução 3: usar General_Purpose.dbc e remover componentes depois

Se você não precisa do banco enxuto desde o início, use o template seed-based e remova componentes via catnoXXX.sql no pós-criação. Não é elegante, mas o DBCA não falha.

⚠️ Custo dessa abordagem: o banco nasce com JVM, XDB, Text, Spatial, etc. Cada componente removido depois exige downtime e scripts oficiais (catnojav.sql, catnoxdb.sql, etc.). Para um banco que será destino de Data Pump com schemas limpos, a Solução 1 ou 2 é melhor.

Checklist rápido

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;

Resultado esperado num banco criado com New_Database.dbt + 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                       VALID

Cinco entradas. Zero componentes opcionais. Exatamente o objetivo.

Lições aprendidas

✅ O glogin.sql é invisível, mas executa em tudo. Toda conexão sqlplus do host (catcon, AutoUpgrade, datapatch, scripts próprios) passa por ele. Um glogin com PL/SQL implícito quebra operações críticas silenciosamente.

✅ O parâmetro dbOptions só tem efeito com New_Database.dbt. O General_Purpose.dbc ignora dbOptions porque os componentes já estão nos datafiles seed.

✅ Passe dbOptions na linha de comando, não no response file. A versão na linha de comando é mais confiável e independente do template.

✅ A mensagem unexpected error in validate_credentials é enganosa. Não tem nada a ver com autenticação. Sempre que ela aparecer durante criação de banco, abra o .lst detalhado e procure ORA- próximo a Connected..

✅ Nunca use set serveroutput on no glogin.sql. É PL/SQL implícito. Use no login.sql do usuário, se necessário.

Referências

Testado em: Oracle Database 19c Enterprise Edition Release 19.29.0.0.0, Oracle Linux, Oracle Restart (HAS), ASM (+DATA / +ARCH).

Share.

Related Posts

0 0 votes
Article Rating
Subscribe
Notify of
guest

0 Comments
Oldest
Newest Most Voted