Olá DBAs, a vida tá boa? É… eu sei, to meio sumido, mas é complicado ser seletivo nos posts.. auhauhauhuhaa, ainda mais quando se tem por perto um grupo incrível como é o pessoal do GUOB (Grupo de Usuários Oracle do Brasil). No grupo de whatsapp com essa galera incrível, sempre aparecem muitos posts bons e muito úteis, o que torna a seleção de assuntos pra postar aqui ainda mais difícil, mas… finalmente achei algo que acredito que vale a pena escrever, então… vambora!!!
Voce deve estar se perguntando, porque falarmos de um PSU do 12c? Pior ainda, 12.1, a versão estável já é a 19, o 23 AI já tá aí… siiimmm.. mas lembre-mo-nos (essa palavra coube lindamente aqui), muito, mas muito cliente mantém seus DB´s em versões antigas. Concordamos? Não. Apoiamos? Não. Mas eles tem seus motivos e a gente é pago pra resolver os problemas que as vezes eles mesmos criam, certo? 🙂
Bom, esse cliente em específico tem uma quantidade imensa de Db´s em 12.1, em torno de 160 Db´s, e após serem adquiridos por uma multinacional, conseguiram convencer a galera de cima a não fazer o upgrade pois pretendem decomissionar estes databases ainda em 2025, mas foram exigidos a sair pelo menos do base release e aplicar os patches. Deveria ser o último PSU lançado pra versão? Deveria. É esta que está sendo aplicada? Não é. Eu sei porque? Não sei. Cheguei no projeto aos 45 do segundo tempo já com todas as decisões tomadas e só me queriam para o trabalho braçal de aplicar este patch até o final de Dezembro. São 160 databases, e eu cheguei no projeto dia primeiro de Dezembro, onde o cliente ainda não sabia quais eram os bancos que eles tinham em seu DC e também não sabia as aplicações relacionadas a eles. Sem tempo para automatizar (FFP, ansible, OEM eram soluções possíveis, mas não dessa vez), comecei o discovery do ambiente, fiz o planejamento e apesar de já estarmos em Fevereiro, o primeiro patch pós toda fase de planning foi aplicado dia 10 de Fevereiro, e estamos indo de vento em popa. Acredito que terminamos até o meio Março as fases de DEV e TEST, a então produção começará em Abril.
Dadas as devidas explicações do cenário pra não gerar discussão ou debates sobre o porque disso, porque daquilo, etc. e tals… vamos agora ao real objetivo do artigo, mostrar o erro que enfrentei em alguns destes ambientes, e apesar de ser chatinho pra descobrir (só sofri da primeira vez), a solução é muito, muito simples.
Estava aplicando o Combo Patch (que conta com DB e OJVM Patch 34163630 – Combo of OJVM Component 12.1.0.2.220719 DB PSU + DB PSU 12.1.0.2.220719), mas o problema se deu no patch 34057742 Database PSU quando atualizando o dicionário pelo datapatch:
Current state of SQL patches:
Patch 34086863 (Database PSU 12.1.0.2.220719,Oracle JavaVM Component (JUL2022)):
Installed in the binary registry only
Bundle series PSU:
ID 220719 in the binary registry and ID 161018 in the SQL registry
Adding patches to installation queue and performing prereq checks...
Installation queue:
Nothing to roll back
The following patches will be applied:
34086863 (Database PSU 12.1.0.2.220719,Oracle JavaVM Component (JUL2022))
34057742 (DATABASE PATCH SET UPDATE 12.1.0.2.220719)
Installing patches...
Patch installation complete. Total patches installed: 2
Validating logfiles...
Patch 34086863 apply: SUCCESS
logfile: /u00/oracle/cfgtoollogs/sqlpatch/34086863/24841635/34086863_apply_PBLMCHATO_2025Feb12_08_21_17.log (no errors)
Patch 34057742 apply: WITH ERRORS
logfile: /u00/oracle/cfgtoollogs/sqlpatch/34057742/24873298/34057742_apply_PBLMCHATO_2025Feb12_08_22_07.log (errors)
Error at line 65600: Warning: Package Body created with compilation errors.
Error at line 65607: 1161/5 PL/SQL: Statement ignored
Error at line 65608: 1161/5 PLS-00201: identifier 'UTL_FILE' must be declared
Error at line 65609: 1167/5 PL/SQL: Statement ignored
Error at line 65610: 1167/5 PLS-00201: identifier 'UTL_FILE' must be declaredAo checar o database, foi possível ver e confirmar o problema:
SQL> select TO_CHAR(action_time, 'YYYY-MM-DD') as action_time,
patch_id, action, description, version,
status from dba_registry_sqlpatch; 2 3
ACTION_TIM PATCH_ID ACTION DESCRIPTION VERSION STATUS
---------- ---------- --------------- ---------------------------------------------------------------------------------------------------- -------------------- ---------------
2022-03-15 24006101 APPLY Database Patch Set Update : 12.1.0.2.161018 (24006101) 12.1.0.2 SUCCESS
2025-02-12 34086863 APPLY Database PSU 12.1.0.2.220719,Oracle JavaVM Component (JUL2022) 12.1.0.2 SUCCESS
2025-02-12 34057742 APPLY DATABASE PATCH SET UPDATE 12.1.0.2.220719 12.1.0.2 WITH ERRORSBom, primeiramente me causou estranheza, de porque durante a atualização do dicionário pós patch, eu estava recebendo um erro de permissão, já que em teoria estou conectado como SYSDBA e deveria poder ver, ler, fazer tudo no database.
Primeira coisa, analisar o log né a procura de erros e ver o que poderia fazer sentido neste contexto. E vamos lá:
########### Conteúdo do log de apply ###########
...
Warning: Package Body created with compilation errors.
SQL> show errors
Errors for PACKAGE BODY XDB.DBMS_XDB_ADMIN:
LINE/COL ERROR
-------- -----------------------------------------------------------------
1161/5 PL/SQL: Statement ignored
1161/5 PLS-00201: identifier 'UTL_FILE' must be declared
1167/5 PL/SQL: Statement ignored
1167/5 PLS-00201: identifier 'UTL_FILE' must be declared
SQL> create or replace package body xdb.dbms_xdb_print wrapped
2 a000000
...
########### Conteúdo do log de apply ########### Uma package do XDB não está compilando. Interessante. Próximo passo foi checar os componentes pra saber se algum estava com problema:
select comp_id, comp_name, version, status from dba_registry;SQL> SQL>
COMP_ID COMP_NAME VERSION STATUS
-------------------- ---------------------------------------- ------------------------------ --------
OWM Oracle Workspace Manager 12.1.0.2.0 VALID
XDB Oracle XML Database 12.1.0.2.0 VALID
CATALOG Oracle Database Catalog Views 12.1.0.2.0 VALID
CATPROC Oracle Database Packages and Types 12.1.0.2.0 VALID
JAVAVM JServer JAVA Virtual Machine 12.1.0.2.0 VALID
XML Oracle XDK 12.1.0.2.0 VALID
CATJAVA Oracle Database Java Packages 12.1.0.2.0 VALID
7 rows selected.Tá tudo bonitinho, que estranho! Vamos checar os objetos inválidos neste banco. UTLRP no bicho:
### Trying to recompile objects ###
ERRORS DURING RECOMPILATION
---------------------------
0
Function created.
PL/SQL procedure successfully completed.
Function dropped.
Warning: XDB now invalid, invalid objects found:
object_name object_type
-------------------------------------------------------
DBMS_XDB_ADMIN PACKAGE BODY
DBMS_XMLPARSER PACKAGE BODY
DBMS_XSLPROCESSOR PACKAGE BODY
DBMS_CLOBUTIL PACKAGE BODY
DBMS_CLOBUTIL PACKAGE
PL/SQL procedure successfully completed.
SQL> select comp_id, comp_name, version, status from dba_registry;SQL> SQL>
COMP_ID COMP_NAME VERSION STATUS
-------------------- ---------------------------------------- ------------------------------ --------
OWM Oracle Workspace Manager 12.1.0.2.0 VALID
XDB Oracle XML Database 12.1.0.2.0 INVALID
CATALOG Oracle Database Catalog Views 12.1.0.2.0 VALID
CATPROC Oracle Database Packages and Types 12.1.0.2.0 VALID
JAVAVM JServer JAVA Virtual Machine 12.1.0.2.0 VALID
XML Oracle XDK 12.1.0.2.0 VALID
CATJAVA Oracle Database Java Packages 12.1.0.2.0 VALID
7 rows selected.
### Trying to recompile objects ### Olha que interessante, após tentar recompilar os objetos no banco de dados, meu XDB se tornou inválido, pois encontrou objetos do XDB com problemas que não permitiam que o mesmo permanecesse válido.
Bom, não compilaram os objetos e ainda invalidaram meu XDB, pois a package é a de ADM do XDB e já que sem ela nada no XDB funcionaria, o processo no banco de dados marca o componente como inválido.
Bom.. até aqui, diagnóstico correndo legal, mas se olharmos todas as etapas, a root cause do meu problema é o UTL_FILE que não está sendo vísivel pela package do XDB (e consequentemente os outros objetos falham também). To no meio do fogo, não posso esmiuçar o XDB agora, pra procurar owner, permissões, etc… quero resolver rápido pra poder entregar o ambiente. Bom, se o owner não está vendo o UTL_FILE, ele com certeza não tem o grant direto pra si e o PUBLIC também não tem. Mas peraí? Até onde sei o grant de execute no UTL_FILE pra PUBLIC é padrão (exceto em empresas onde se empregam regras de segurança mais rígidas e é solicitado que esse grant seja revogado) mas via de regra, este grant deve estar lá.
Vamos a tentativa:
SQL> grant execute on utl_file to public;
Grant succeeded.
SQL> @?/rdbms/admin/utlrp
TIMESTAMP
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
COMP_TIMESTAMP UTLRP_BGN 2025-02-12 08:47:14
DOC> The following PL/SQL block invokes UTL_RECOMP to recompile invalid
DOC> objects in the database. Recompilation time is proportional to the
DOC> number of invalid objects in the database, so this command may take
DOC> a long time to execute on a database with a large number of invalid
DOC> objects.
DOC>
DOC> Use the following queries to track recompilation progress:
DOC>
DOC> 1. Query returning the number of invalid objects remaining. This
DOC> number should decrease with time.
DOC> SELECT COUNT(*) FROM obj$ WHERE status IN (4, 5, 6);
DOC>
DOC> 2. Query returning the number of objects compiled so far. This number
DOC> should increase with time.
DOC> SELECT COUNT(*) FROM UTL_RECOMP_COMPILED;
DOC>
DOC> This script automatically chooses serial or parallel recompilation
DOC> based on the number of CPUs available (parameter cpu_count) multiplied
DOC> by the number of threads per CPU (parameter parallel_threads_per_cpu).
DOC> On RAC, this number is added across all RAC nodes.
DOC>
DOC> UTL_RECOMP uses DBMS_SCHEDULER to create jobs for parallel
DOC> recompilation. Jobs are created without instance affinity so that they
DOC> can migrate across RAC nodes. Use the following queries to verify
DOC> whether UTL_RECOMP jobs are being created and run correctly:
DOC>
DOC> 1. Query showing jobs created by UTL_RECOMP
DOC> SELECT job_name FROM dba_scheduler_jobs
DOC> WHERE job_name like 'UTL_RECOMP_SLAVE_%';
DOC>
DOC> 2. Query showing UTL_RECOMP jobs that are running
DOC> SELECT job_name FROM dba_scheduler_running_jobs
DOC> WHERE job_name like 'UTL_RECOMP_SLAVE_%';
DOC>#
PL/SQL procedure successfully completed.
TIMESTAMP
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
COMP_TIMESTAMP UTLRP_END 2025-02-12 08:47:16
DOC> The following query reports the number of objects that have compiled
DOC> with errors.
DOC>
DOC> If the number is higher than expected, please examine the error
DOC> messages reported with each object (using SHOW ERRORS) to see if they
DOC> point to system misconfiguration or resource constraints that must be
DOC> fixed before attempting to recompile these objects.
DOC>#
OBJECTS WITH ERRORS
-------------------
0
DOC> The following query reports the number of errors caught during
DOC> recompilation. If this number is non-zero, please query the error
DOC> messages in the table UTL_RECOMP_ERRORS to see if any of these errors
DOC> are due to misconfiguration or resource constraints that must be
DOC> fixed before objects can compile successfully.
DOC>#
ERRORS DURING RECOMPILATION
---------------------------
0
Function created.
PL/SQL procedure successfully completed.
Function dropped.
PL/SQL procedure successfully completed.
SQL>
SQL> col comp_id for A20
col comp_name for A50
select comp_id, comp_name, version, status from dba_registry;SQL> SQL>
COMP_ID COMP_NAME VERSION STATUS
-------------------- ---------------------------------------- ------------------------------ --------
OWM Oracle Workspace Manager 12.1.0.2.0 VALID
XDB Oracle XML Database 12.1.0.2.0 VALID
CATALOG Oracle Database Catalog Views 12.1.0.2.0 VALID
CATPROC Oracle Database Packages and Types 12.1.0.2.0 VALID
JAVAVM JServer JAVA Virtual Machine 12.1.0.2.0 VALID
XML Oracle XDK 12.1.0.2.0 VALID
CATJAVA Oracle Database Java Packages 12.1.0.2.0 VALID
7 rows selected.Olha que lindo. Não é que resolveu?
Vamos voltar ao patch, e tentar aplicar novamente no database via datapatch:
[oracle@linux-valdz OPatch]$ ./datapatch -verbose
SQL Patching tool version 12.1.0.2.0 Production on Wed Feb 12 08:48:29 2025
Copyright (c) 2012, 2016, Oracle. All rights reserved.
Log file for this invocation: /u00/oracle/cfgtoollogs/sqlpatch/sqlpatch_21663_2025_02_12_08_48_29/sqlpatch_invocation.log
Connecting to database...OK
Bootstrapping registry and package to current versions...done
Determining current state...done
Current state of SQL patches:
Patch 34086863 (Database PSU 12.1.0.2.220719,Oracle JavaVM Component (JUL2022)):
Installed in the binary registry and the SQL registry
Bundle series PSU:
ID 220719 in the binary registry and ID 220719 with errors in the SQL registry
Adding patches to installation queue and performing prereq checks...
Installation queue:
Nothing to roll back
The following patches will be applied:
34057742 (DATABASE PATCH SET UPDATE 12.1.0.2.220719)
Installing patches...
Patch installation complete. Total patches installed: 1
Validating logfiles...
Patch 34057742 apply: SUCCESS
logfile: /u00/oracle/cfgtoollogs/sqlpatch/34057742/24873298/34057742_apply_PBLMCHATO_2025Feb12_08_48_43.log (no errors)
SQL Patching tool complete on Wed Feb 12 08:48:50 2025
SQL> set lines 999
set pages 999
select TO_CHAR(action_time, 'YYYY-MM-DD') as action_time,
patch_id, action, description, version,
status from dba_registry_sqlpatch;
SQL> SQL> 2 3
ACTION_TIM PATCH_ID ACTION DESCRIPTION VERSION STATUS
---------- ---------- --------------- ---------------------------------------------------------------------------------------------------- -------------------- ---------------
2022-03-15 24006101 APPLY Database Patch Set Update : 12.1.0.2.161018 (24006101) 12.1.0.2 SUCCESS
2025-02-12 34086863 APPLY Database PSU 12.1.0.2.220719,Oracle JavaVM Component (JUL2022) 12.1.0.2 SUCCESS
2025-02-12 34057742 APPLY DATABASE PATCH SET UPDATE 12.1.0.2.220719 12.1.0.2 WITH ERRORS
2025-02-12 34057742 APPLY DATABASE PATCH SET UPDATE 12.1.0.2.220719 12.1.0.2 SUCCESSShow de Bola! Patch aplicado com sucesso!!!
Agora, como diz um amigo meu muito conhecido pelos DBAs aqui da minha região, se voce encontrar uma tartaruga em cima de uma árvore, não tira ela de lá, pois voce não sabem quem e nem por qual motivo ela foi colocada ali, sendo assim, vamos revogar o grant:
SQL> revoke execute on utl_file from public;
Revoke succeeded.Prontinho. Precisei fuçar na sala de alguém, mas no final coloquei tudo de volta no lugar.
Alguns dias depois, eu estava procurando informações para este post sobre o privilégio de execute no UTL_FILE para o PUBLIC, e acabei encontrando o seguinte note que fala do mesmo problema:
datapatch fail with PLS-00201: identifier ‘UTL_FILE’ must be declared (Doc ID 2269509.1)
Nele, algumas das descrições dão conta de como o privilégio deveria estar lá e o resumo da ópera é o seguinte:
“The cause of the issue is invalid database component XDB and objects under XDB.
The root cause for XDB getting invalid has been determined as “UTL_FILE doesn’t have EXECUTE privilege to PUBLIC, thus leaving the XDB components and objects in INVALID state. The EXECUTE privilege on UTL_FILE to PUBLIC is mandatory for XDB to be valid.”Doc ID 2269509.1
Ou seja, deveria ter procurado no MOS desde o início e isso me pouparia sair a caça do problema, ficar imaginando, ligando pontos e cavando. Mas, quem resiste a um bom throubleshooting?
Acredito que o mesmo valha para as versões pós 12c, apesar de ainda não ter passado pelo mesmo em outros ambientes.
Como sempre, Fiquem a vontade para fazer quaisquer pontuações caso já tenham vivenciado algo do tipo.
Essa é a dica 0800 pra vocês desta vez.
“Saber das coisas vale ouro. Compartilhar esse conhecimento não tem preço.”
Um comentário em “ERRO aplicando Database Patch Set Update 12.1.0.2.220719Patch”