Olá DBAs, a vida tá boa? Vamos ao assuntinho desse post, que acredito vá interessar a nós meros mortais que seguimos (quando possível) o planejamento de aplicar os quarter patches nos nossos clientes 🙂
Lembram do meu último post?
Bem, continuamos a saga com esses patches! Dessa vez temos outro caso onde o mesmo foi diagnosticado, endereçado e corrigido. Especificamente para este Patch Set Update 12.1.0.2.220719 Patch estou enfrentando conflitos com one-off patch em algumas das bases como a seguir:
Analysis for applying patches has failed:
Host: linux-valdz
SIDB Home:/OH12/oracle/prod/12.1.0.2
Version:12.1.0.2.0
Analysis for patches has failed.
==Following patches FAILED in analysis for apply:
Patch: <patch_location>/34057742
Log: /OH12/oracle/prod/12.1.0.2/cfgtoollogs/opatchauto/core/opatch/opatch2025-03-15_09-09-57AM_1.log
Reason: Failed during Analysis: CheckConflictAgainstOracleHome Failed, [ Prerequisite Status: FAILED, Prerequisite output:
Summary of Conflict Analysis:
Patches that can be applied now without any conflicts are :
32758932
Following patches have conflicts. Please contact Oracle Support and get the merged patch of the patches :
21131203, 34057742
Whole composite patch Conflicts/Supersets are:
Composite Patch : 34057742
Conflict with 21131203
A Mensagem de erro é clara, pedindo para entrar em contat com a Oracle solicitando um merged patch. Não preciso nem dizer o quão moroso pode ser isso:
– Abrir Service Request
– Esperar o primeiro contato
– Responder a um zilhão de questões
– Voltar provavelmente a algumas questões que já fizeram e tão fazendo de novo
– Receber análise com possível solução
O procedimento acima é muito conhecido por nós DBAs, e neste meu caso específico, como não era produção (estamos aplicando nos lower environments primeiro) seria ainda mais moroso, mais lento, mais chato!
Decidi então dar uma pesquisada no que poderia ser feito. Eu poderia fazer rollback do patch 21131203 para aplicar o novo que preciso, mas nesse ponto surgiram duvidas do tipo:
– “Se eu fizer rollback, conseguirei aplica-lo novamente?”
– “Eu preciso dos files do patch para fazer o rollback?”
– “Será que o bug deste one-off patch já foi corrigido neste patch que estou aplicando?”.
Algumas das questões podem parecer básicas ou simples, mas pelo menos da minha parte, patches não são algo que aplico todo dia, aí toda vez que vou fazer me deparo com algumas duvidas devido a situações novas.
Inicialmente, para as perguntas acima, minhas respostas eram respectivamente “Não”, “Sim” e “Não”.
Após me aprofundar mais sobre o assunto, elas mudaram para “Talvez”, “Não” e “Não”.
Se eu fizer rollback, conseguirei aplica-lo novamente?
Não, não será possível aplicar o one-off patch novamente (afinal ele entra em conflito com o PSU aplicado) a não ser que haja um novo específico para o mesmo problema. Caso haja a resposta é Sim.
Eu preciso dos files do patch para fazer o rollback?
Não, os arquivos do one-off patch não são necessários para que eu possa fazer rollback do mesmo. Na verdade nenhum patch precisa dos arquivos para que o rollback seja executado. Se voce olhar a documentação, verá que para executar um rollback é necessário o seguinte comando:
$ opatch rollback -id <patch number>
Bom, fiquei em dúvida sobre como ele consegue fazer o rollback sem ter os arquivos originais, e tive a oportunidade e o privilégio de buscar na fonte, conversando com o grande amigo e conhecido de todos nós aqui, o PM da Oracle Rodrigo Jorge (https://www.dbarj.com.br/en/) que foi super esclarecedor:
– Quando vc instala um patch, os arquivos de aplicar e voltar ficam no Oracle Home, então vc não precisa mais dos arquivos do patch, voce basicamente roda o comando opatch com rollback pra remover do binário, pois dentro do ORACLE_HOME da pasta .patch_storage ele guarda os arquivos que tinham antes do patch ser instalado e que foram substituídos por ele. Então o comando de rollback volta esses arquivos.
Jorge, Rodrigo – 2025
Sacaram pequenos padawans? Não precisa da pasta do patch, pois o controle dele fica no .patch_storage, e vale a ressalva que o Rodrigo Jorge me fez durante nossa conversa:
– Agora se vc limar essa pasta pra salvar espaço, aí já era “parxeiro”!!!
Jorge, Rodrigo – 2025 (falando como um bom carioca)
Pois é, então tenha a preocupação de saber se voce talvez um dia em algum momento irá precisar fazer rollback, antes de apagar a pasta .patch_storage para salvar espaço no seu servidor. Sei que não é comum, mas no desespero, já viu né.
Rodrigo Jorge, muito obrigado pelos esclarecimentos que ajudaram este artigo a ficar mais completo.
Será que o bug deste one-off patch já foi corrigido neste patch que estou aplicando?
Não, este bug não foi corrigido na nova versão pois não encontrei o número dele dentro da lista de patches que serão aplicados pelo PSU que quero aplicar, apesar da Oracle informar que ele está corrigo no Bundle patch de Jan-2017. Preferi não arriscar e verificar como poderia aplica-lo novamente.
Então, o que fazer? Em alguma reunião alguém disse: “Vamos utilizar o parametro -skip_conflict”, neste momento os olhos da gerencia brilharam pois soava como uma luz no fim do tunel que poderia evitar uma SR com a Oracle. Fiquei triste em ser o portador da má notícia, informando que o skip_conflict iria somente evitar o patch conflitante, não o aplicando, e que não resolveria o problema.
-skip_conflict
If a conflict exist which prevents the patch from being applied, this flag can be used to skip the conflicting patches. Remaining patches will be applied after skipping conflicting patches. Pensei então no -force_conflict, afinal a função dele seria remover o patch conflitante (no meu caso o one-off patch 21131203) para que o PSU (patch 34057742) pudesse ser aplicado. Mas…
– Seria o opatchauto capaz de remover um patch sem ter seus arquivos no server somente com este parametro?
– E após a remoção, se o bug ainda existe, eu precisaria aplica-lo novamente, então melhor certificar-me de que isso é possível.
Como Jack (O estripador) decidi ir por partes. Vamos pesquisar sobre este one-off patch:
Este é o bug, a Oracle informa que o bug está corrigido a partir do Bundle Patch de Janeiro de 2017, mas pesquisando um pouco mais vi o seguinte:
Existem várias versões para este one-off patch, sendo elas específicas pra cada PSU, que vão até 2020, e o meu PSU específico consta nessa lista. Sendo assim, prezando pela minha saúde mental e paz de espírito, é melhor aplicar este one-off patch após o PSU.
Bom, ponto 1 resolvido. Vamos ao ponto 2.
Como fazer o roolback deste one-off patch sem os arquivos? Bom, eu não preciso deles mesmo ao usar o parametro -force_conflict no opatchauto.
-force_conflict
If a conflict exist which prevents the patch from being applied, this flag can be used to force application of the patch. All the conflicting patches will be removed before applying the current patch.Analysis for applying patches has completed successfully:
Host: linux-valdz
SIDB Home: :/OH12/oracle/prod/12.1.0.2
Version:12.1.0.2.0
==Following patches were SUCCESSFULLY analyzed to be applied:
Patch: <patch_location>/32758932
Log:/OH12/oracle/prod/12.1.0.2/cfgtoollogs/opatchauto/core/opatch/opatch2025-02-19_07-49-49AM_1.log
Patch: <patch_location>/34057742
Log:/OH12/oracle/prod/12.1.0.2/cfgtoollogs/opatchauto/core/opatch/opatch2025-02-19_07-49-49AM_1.log
Olha que show! Opatchauto passou sem problemas utilizando o -force_conflict, o que significa que ele irá fazer rollback do one-off patch conflitante e aplicará o PSU corretamente.
Após aplicar o patch corretamente, baixei o one-off patch na versão específica para o meu atual PSU e apliquei ele no database, o que ocorreu normalmente e sem nenhum problema:
INVENTORY
Oracle Interim Patch Installer version 12.2.0.1.43
Copyright (c) 2025, Oracle Corporation. All rights reserved.
Oracle Home : :/OH12/oracle/prod/12.1.0.2
from : :/OH12/oracle/prod/12.1.0.2/oraInst.loc
OPatch version : 12.2.0.1.43
OUI version : 12.1.0.2.0
Log file location : :/OH12/oracle/prod/12.1.0.2/cfgtoollogs/opatch/opatch2025-02-19_09-12-15AM_1.log
Lsinventory Output file location : :/OH12/oracle/prod/12.1.0.2/cfgtoollogs/opatch/lsinv/lsinventory2025-02-19_09-12-15AM.txt
--------------------------------------------------------------------------------
Local Machine Information::
Hostname: linux-valdz
ARU platform id: 226
ARU platform description:: Linux x86-64
Installed Top-level Products (1):
Oracle Database 12c 12.1.0.2.0
There are 1 products installed in this Oracle Home.
Interim patches (4) :
Patch 21131203 : applied on Wed Feb 19 09:11:51 EST 2025
Unique Patch ID: 24846831
Created on 1 Jul 2022, 04:22:13 hrs PST8PDT
Bugs fixed:
21131203
This patch overlays patches:
34057742
This patch needs patches:
34057742
as prerequisites
Patch 34086863 : applied on Wed Feb 19 09:07:58 EST 2025
Unique Patch ID: 24841635
Patch description: "Database PSU 12.1.0.2.220719,Oracle JavaVM Component (JUL2022)"
Created on 29 Jun 2022, 08:00:17 hrs UTC
…
Patch 34057742 : applied on Wed Feb 19 08:44:27 EST 2025
Unique Patch ID: 24873298
Patch description: "Database Patch Set Update : 12.1.0.2.220719 (34057742)"
Created on 21 Jul 2022, 04:32:03 hrs PST8PDT
Sub-patch 33711081; "Database Patch Set Update : 12.1.0.2.220419 (33711081)"
Sub-patch 33477199; "Database Patch Set Update : 12.1.0.2.220118 (33477199)"
Sub-patch 33128590; "Database Patch Set Update : 12.1.0.2.211019 (33128590)"
Sub-patch 32768233; "Database Patch Set Update : 12.1.0.2.210720 (32768233)"
Sub-patch 32328635; "Database Patch Set Update : 12.1.0.2.210420 (32328635)"
Sub-patch 31985579; "Database Patch Set Update : 12.1.0.2.210119 (31985579)"
Sub-patch 31550110; "Database Patch Set Update : 12.1.0.2.201020 (31550110)"
Sub-patch 31113348; "Database Patch Set Update : 12.1.0.2.200714 (31113348)"
Sub-patch 30700212; "Database Patch Set Update : 12.1.0.2.200414 (30700212)"
Sub-patch 30340202; "Database Patch Set Update : 12.1.0.2.200114 (30340202)"
Sub-patch 29918340; "Database Patch Set Update : 12.1.0.2.191015 (29918340)"
Sub-patch 29494060; "Database Patch Set Update : 12.1.0.2.190716 (29494060)"
Sub-patch 29141015; "Database Patch Set Update : 12.1.0.2.190416 (29141015)"
Sub-patch 28729169; "Database Patch Set Update : 12.1.0.2.190115 (28729169)"
Sub-patch 28259833; "Database Patch Set Update : 12.1.0.2.181016 (28259833)"
Sub-patch 27547329; "Database Patch Set Update : 12.1.0.2.180717 (27547329)"
Sub-patch 27338041; "Database Patch Set Update : 12.1.0.2.180417 (27338041)"
Sub-patch 26925311; "Database Patch Set Update : 12.1.0.2.180116 (26925311)"
Sub-patch 26713565; "Database Patch Set Update : 12.1.0.2.171017 (26713565)"
Sub-patch 26609783; "Database Patch Set Update : 12.1.0.2.170814 (26609783)"
Sub-patch 25755742; "Database Patch Set Update : 12.1.0.2.170718 (25755742)"
Sub-patch 25171037; "Database Patch Set Update : 12.1.0.2.170418 (25171037)"
Sub-patch 24732082; "Database Patch Set Update : 12.1.0.2.170117 (24732082)"
Sub-patch 24006101; "Database Patch Set Update : 12.1.0.2.161018 (24006101)"
Sub-patch 23054246; "Database Patch Set Update : 12.1.0.2.160719 (23054246)"
Sub-patch 22291127; "Database Patch Set Update : 12.1.0.2.160419 (22291127)"
Sub-patch 21948354; "Database Patch Set Update : 12.1.0.2.160119 (21948354)"
Sub-patch 21359755; "Database Patch Set Update : 12.1.0.2.5 (21359755)"
Sub-patch 20831110; "Database Patch Set Update : 12.1.0.2.4 (20831110)"
Sub-patch 20299023; "Database Patch Set Update : 12.1.0.2.3 (20299023)"
Sub-patch 19769480; "Database Patch Set Update : 12.1.0.2.2 (19769480)"Sendo assim, o problema do conflito foi resolvido sem que eu precisasse abrir uma SR na Oracle, salvando muito tempo para atingir o objetivo que era aplicar este PSU sem maiores problemas.
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.”
