Aplicando RELEASE UPDATE (RU) no Oracle 12.2

Introdução

Neste artigo, será demonstrado de forma pratica a execução de um procedimento a qual um ambiente produtivo Oracle database com estrutura em cluster (RAC) é submetido a aplicação do patch RELEASE UPDATE (RU), no decorrer do texto é explanado detalhes teóricos, abordando alguns conceitos referente a este tema.

Recomenda-se que a leitura deste artigo seja feita de forma cronológica atentando-se ao entendimento de cada ação executada, no decorrer do texto também serão apresentadas notas (oficiais e não oficiais) para leituras complementares, bem como scripts que serão usados para automação de etapas do procedimento.

O que é RELEASE UPDATE (RU)?

Trata-se de um patch publicado trimestralmente pela Oracle Corporation, utilizado a partir da versão 12.2 (12cR2), que abrange “proactive fix” (cujo intuito é evitar problemas conhecidos proativamente - BUG) e “security fix” (correções de segurança). Desde o segundo semestre de 2017 foi anunciado uma transição na estratégia de lançamento de releases do oracle database software, essa alteração abrange o Database e Grid Infrastructure a partir da versão 12.2, sendo assim, versões 12.1 e inferiores não estão incluídas na nova estratégia, portanto, os conceitos aqui apresentados não são validos para versões inferiores a 12.2.

• Release Update Introduction and FAQ (Doc ID 2285040.1

Antes de iniciar as narrativas referente ao tema, vale mostrar uma importante referência, a qual trata-se da nota "Doc ID 2118136.2", esta nota se apresenta como um simples e didático assistente para busca e posterior download das diversas medias que alude o Oracle Database, a seguir será demostrado seu arranjo, mais adiante após a apresentação do "cenário/contexto de infraestrutura" que será utilizado neste artigo, será exibido como localizar as medias necessárias, utilizando esta nota ("Doc ID 2118136.2").

• Assistant: Download Reference for Oracle Database/GI Update, Revision, PSU, SPU(CPU), Bundle Patches, Patchsets and Base Releases (Doc ID 2118136.2)

Aplicação de Patch RELEASE UPDATE (RU)

Detalhes relevantes do artigo:

Cenário/Contexto de infraestrutura:

• Oracle Real Application Clusters (Oracle RAC) - 2 Nodes
• Sistema Operacional: Linux Red Hat 7.4 x86 64bits (x86_64)
• Oracle Grid Infrastructure (GI): 12.2.0.1.0 - Enterprise Edition - Linux-x86-64
• Oracle Database (RDBMS): 12.2.0.1.0 - Enterprise Edition - Linux-x86-64
• Instalação do software oracle sem "role segregation" entre RDBMS e GI, ou seja, o usuário UNIX "oracle" é owner do RDBMS e GI.

Atividade a ser realizada:

• Aplicação do RELEASE UPDATE (RU) 12.2.0.1.190416, nas camadas Grid Infrastructure (GI) e Database (RDBMS).
  
  • RELEASE UPDATE (RU) 12.2.0.1.190416 foi lançado em Abril/2019 (RU mais atual até o momento da escrita deste artigo - Maio/2019).
  • Patch que será aplicado   : Oracle Database Patch 29301687 - GI Apr 2019 Release Update 12.2.0.1.190416
  • Nota MOS - Patch 29301687 : GI APR 2019 RELEASE UPDATE 12.2.0.1.190416
  • p29301687_122010_Linux-x86-64.zip

• Atualização do utilitário OPatch, para o mais atual que seja compatível com a versão 12.2.
  
  • OPatch utilizado será o 12.2.0.1.17  (OPatch mais atual até o momento da escrita deste artigo - Maio/2019).
  • Nota MOS - Patch 6880880: OPatch 12.2.0.1.17 for DB 12.x and 18.x releases
  • p6880880_122010_Linux-x86-64.zip

Notas relevantes para leitura complementar deste artigo para melhor compreensão deste procedimento.

• Master Note for Database Proactive Patch Program (Doc ID 756671.1)        
• Database 12.2.0.1 Proactive Patch Information (Doc ID 2285557.1)
• Bug 29301687 - Grid Infrastructure Apr 2019 Release Update (GI RU) 12.2.0.1.190416 (Doc ID 29301687.8)
• Assistant: Download Reference for Oracle Database/GI Update, Revision, PSU, SPU(CPU), Bundle Patches, Patchsets and Base Releases (Doc ID 2118136.2)    
• How To Do The Prerequisite/Conflicts Checks Using OUI(Oracle Universal Installer) And OPatch Before Applying/Rolling Back A Patch (Doc ID 459360.1)     
• FAQ: OPatch/Patch Questions/Issues for Oracle Clusterware (Grid Infrastructure or CRS) and RAC Environments (Doc ID 1339140.1)  
• Datapatch: Database 12c or later Post Patch SQL Automation (Doc ID 1585822.1)   
• 12.2.0.1 Grid Infrastructure Release Update - List of Fixes in each RU/RUR (Doc ID 2245185.1)
• Release Schedule of Current Database Releases (Doc ID 742060.1)

Termos e terminologias utilizadas neste artigo

[root @ DBAFurushima1 ~] #   →
Go to  root SHELL command prompt [.oracle @ DBAFurushima1 ~] $ → Go   to oracle
GI  SHELL command prompt →   Oracle Grid Infrastructure
RDBMS → Oracle Database
RU →   RELEASE UPDATE
$ STAGE_RU →  RU binary storage location (stage area)
"Auxiliary Variables" →  UNIX environment variables named $ ORACLE_HOME_GI, $ ORACLE_HOME_RDBMS, $ STAGE_RU, $ USER_GI, $ USER_RDBMS and $ LD_LIBRARY_PATH
			

Procedimento

Dividiremos em 4 passos a aplicação do RELEASE UPDATE (RU):

• Preparação, levantamento das mídias necessárias (binários) e validações.
• Atualização ou Upgrade do utilitário OPatch
• Aplicação do RU - RELEASE UPDATE 12.2.0.1.190416
• Validação Final

Passo 1. Preparação, levantamento das mídias necessárias (binários) e validações.

Levantamento da media RELEASE UPDATE (RU) usando a nota "Doc ID 2118136.2" .

• Assistant: Download Reference for Oracle Database/GI Update, Revision, PSU, SPU(CPU), Bundle Patches, Patchsets and Base Releases (Doc ID 2118136.2)

A média RELEASE UPDATE (RU), pertinente ao Clusterware Home (ORACLE_HOME do Grid Infrastructure - GI), identificada na nota como “GI Update” (vide seta verde), NÃO SOMENTE possui conteúdos de "proactive fix" atualização/correção e "security fix" relativo ao Grid Infrastructure (GI), como também do Database RDBMS, podendo assim, ser aplicados de forma contínua (sem necessidade de outro binário, ha que somente um possui o conteúdo de ambos os homes), ou seja, a média RU GI, possui todos os conteúdos necessários para atualizar o GI e RDBMS (não havendo a necessidade do uso do binário RU RDBMS). Isto é apontado na documentação oficial.

Preparação: Área de Stage, medias e validações

Nesta etapa, será eleito um local no filesystem, cujo espaço será destinado ao armazenamento dos PATCHs (RU - RELEASE UPDATE e OPatch). Alguns aspectos referentes a essa etapa devem ser levados em consideração, tais como:

• Eleger um local (para esta área de stage), que seja independente aos HOME de instalação do(os) produto(os) ORACLE, ou seja, um diretório isolado ao ORACLE_BASE e ORACLE_HOME, dessa forma, possíveis erros operacionais serão evitados, durante o procedimento. Neste artigo, foi eleito o diretório /mnt para ser utilizado como área de stage, é valido salientar que este local é de livre escolha do executor, no exemplo utilizado neste artigo o diretório /mnt será a raiz da área de stage.

[root@DBAFurushima1 ~]# df -h /mnt/
Filesystem                             Size  Used Avail Use% Mounted on
/dev/mapper/vg_strip-lv_tecmint_strp1  7.9T  5.4T  2.5T  70% /mnt
			

• Por motivos organizacionais, recomenda-se a criação de subdiretórios na raiz da área de stage, a fim de separar os binários, logs e demais estruturas relevantes ao procedimento.

#####
##### Assignment of STAGE_RU Variable
##### Creating Stage Area Directories  
##### Permission
##### UNIX User = ROOT
#####
[root @ DBAFurushima01 ~] # export STAGE_RU = / mnt / stage / RU
[root @ DBAFurushima01 ~] # mkdir -p $ STAGE_RU / log 
[root @ DBAFurushima01 ~] # mkdir -p $ STAGE_RU / oracle / log
[root @ DBAFurushima01 ~] # mkdir -p $ STAGE_RU / script
[root @ DBAFurushima01 ~] # chmod 777 / mnt /
[root @ DBAFurushima01 ~] # chmod -R 777 / mnt / stage /
			

Após completar as etapas descritas nos parágrafos anteriores, é necessário obter as medias pertinente ao RELEASE UPDATE (RU) e OPatch, essas medias estão disponíveis na forma compactada (.zip) e podem ser obtidas via download no portal MOS (MOS - My Oracle Support ou para os antigos METALINK), com o propósito de facilitar as buscas, no próximo parágrafo serão descritas as notas e suas identificações, para obtenção via download.

• Patch 29301687: GI APR 2019 RELEASE UPDATE 12.2.0.1.190416
• Patch 6880880: OPatch 12.2.0.1.17 for DB 12.x and 18.x releases

É fundamental notabilizar que ambas as notas tocante ao download das medias, traz uma dissociação em tópicos a qual segrega cada link em diferentes binários das várias plataformas que o software oracle database é compatível, neste contexto do artigo, utilizaremos a média referente a plataforma Linux x86-64, ou seja, o binário que será utilizado neste artigo destina-se ao sistema operacional Linux arquitetura x86 64bits.

• Notas complementares:

How To Download And Install The Latest OPatch (6880880) Version (Doc ID 274526.1)
OPatch - Where Can I Find the Latest Version of OPatch (6880880)? [Video] (Doc ID 224346.1)

Após completar as etapas descritas nos parágrafos anteriores, é necessário transferir os binários referente aos PATCHs para a área de stage ($STAGE_RU), que no contexto deste artigo trata-se do diretório /mnt/stage/RU (caso você tenha elegido um caminho diferente ao exemplificado neste artigo, ajuste ao seu cenário).

Cada organização/instituição possui suas regras e regimentos quanto a "security compliance", portanto não será abordado neste artigo, maneiras de download/transferências dos binários entre o MOS (My Oracle Support - Metalink) e o servidor de banco de dados, dado o motivo não uniforme que cada um enfrentará neste passo do procediment

#####
##### Transferência das medias para área de Stage ($STAGE_RU)
##### No cenário do artigo: área de Stage = /mnt/stage/RU/
##### $STAGE_RU  /mnt/stage/RU/
##### Permissionamento das medias
##### Usuário UNIX = ROOT
#####
[root@DBAFurushima1  ~]# cd $STAGE_RU
[root@DBAFurushima1  RU]# pwd
/mnt/stage/RU
[root@DBAFurushima1  RU]# chown oracle:oinstall p29301687_122010_Linux-x86-64.zip
[root@DBAFurushima1  RU]# chown oracle:oinstall p6880880_122010_Linux-x86-64.zip
[root@DBAFurushima1  RU]# chmod 777 p29301687_122010_Linux-x86-64.zip 
p6880880_122010_Linux-x86-64.zip
[root@DBAFurushima1  RU]# ls -la
total 1804700
drwxrwxrwx 2 root   root             99 May  7 12:00 .
drwxrwxrwx 3 root   root             24 May  7 11:44 ..
-rwxrwxrwx 1 oracle oinstall 1736326653 May  7 11:45 p29301687_122010_Linux-x86-64.zip
-rwxrwxrwx 1 oracle oinstall  111682884 May  7 11:45 p6880880_122010_Linux-x86-64.zip
			

Descompacte o arquivo referente ao RELEASE UPDATE (RU), a qual possui a extensão ZIP (p29301687_122010_Linux-x86-64.zip), por meio do utilitário unzip, faça a descompactação do arquivo, cujo destino será o subdiretório oracle da área de stage, ou seja, $STAGE_RU/oracle.

O comando para executar essa ação é mostrado abaixo, bem como seu output de execução:

unzip -q $STAGE_RU/p29301687_122010_Linux-x86-64.zip  -d  $STAGE_RU/oracle/

			

#####
##### Validação da existência do arquivo ZIP (RU)
##### unzip do arquivo p29301687_122010_Linux-x86-64.zip
##### Permissionamento
##### Usuário UNIX = ROOT
#####
[root@DBAFurushima01 ~]# cd $STAGE_RU/
[root@DBAFurushima01 RU]# pwd
/mnt/stage/RU
[root@DBAFurushima01 RU]# ls p29301687_122010_Linux-x86-64.zip
p29301687_122010_Linux-x86-64.zip
[root@DBAFurushima01 RU]# unzip -q $STAGE_RU/p29301687_122010_Linux-x86-64.zip  -d  
$STAGE_RU/oracle/
[root@DBAFurushima01 RU]#
[root@DBAFurushima01 RU]# chmod -R 777 $STAGE_RU/oracle/
[root@DBAFurushima01 RU]# ls -la $STAGE_RU/oracle/
total 0
drwxrwxrwx. 4 root root  33 May 29 11:51 .
drwxrwxrwx. 5 root root 126 May 29 11:48 ..
drwxrwxrwx. 8 root root 159 Mar 25 01:03 29301687
drwxrwxrwx. 2 root root   6 May 29 11:31 log
[root@DBAFurushima01 RU]#

			

NÃO AVANCE PARA OS PROXIMOS STEPS, SEM REALIZAR OS MESMO PROCEDIMENTOS NOS OUTROS NODES DO ORACLE RAC.

OBS. : Repita os mesmos passos, nos demais nodes do ORACLE RAC, antes de prosseguir as próximas fases do procedimento.

OBS.2 : Caso seu ambiente não se tratar de um ORACLE RAC, desconsidere essa informaçã

Resumo das ações executadas até o momento:

1. Introdução as definições pertinentes aos conceitos teóricos que tange RELEASE UPDATE - RU.
2. Overview referente ao assistente para procura de patchs (Nota - Doc ID 2118136.2)
3. Apresentação da Infraestrutura Computacional usada neste artigo
4. Definição da Área de Stage ($STAGE_RU)
5. Medias (binários referentes aos patchs) que são utilizadas no procedimento.
6. Preparação inicial, tais como transferência de medias, Permissionamento etc.

Passo 2. Atualização ou Upgrade do utilitário OPatch

O que é OPatch?

"Oracle Interim One-off Patch Installer", popularmente conhecido como OPatch, trata-se de um utilitário baseado em Java que está integrado em muitos produtos Oracle (inclusive o oracle database GI e RDBMS), deste modo uma instalação do software oracle database GI e/ou RDBMS, também engloba o utilitário OPatch, ou seja, o utilitário OPatch é instalado automaticamente quando você instala o respectivo produto. Sua incumbência é auxiliar no processo de aplicação (apply), reversão (rollback) e detecção de conflito de "patchs corretivos" ("proactive fix", "security fix", "bug fix", "one-off", etc...).

É importante citar que o termo "patch" ou "patches" (referindo o sujeito no plural), neste contexto refere-se de forma genérica (ou global) aos diversos tipos de arquivos que irão prover algum ou alguns tipo(os) de correção(cões) ao software oracle database (GI e/ou RDBMS), em outras palavras, "patch" ou "patches" trata-se de uma coleção de arquivos que ao serem submetidos ou aplicados (apply) via OPatch, são copiados para uma instalação existente, substituindo arquivos atuais ou tornando uma novo arquivo na instalação em caso do mesmo não existir previamente.

O OPatch está localizado no HOME da instalação do produto oracle, neste caso, o ORACLE_HOME, como mostrado nas imagens abaixo:

OBS.: OPatch é identificado pelo número 6880880 no portal MOS (My Oracle Support - Metalink).

Notas complementares:

https://docs.oracle.com/cd/E24628_01/doc.121/e39376/opatch_overview.htm#OPTCH350

Nesta etapa é demonstrado a realização de um update (atualização) da versão do utilitário OPatch. O procedimento será demonstrado em um único node do Oracle Real Application Clusters (Oracle RAC), portanto subentende-se que o mesmo procedimento deve ser realizado em todos os demais nodes que compõem o cluster Oracle RAC.

No transcorrer deste artigo, será chamado a atenção da necessidade de realizar os mesmos procedimentos nos demais nodes do cluster (Oracle RAC), porém os steps desta execução não serão demonstrados, pelo simples motivo de que não haver quaisquer diferença nas execuções entre os nodes do cluster, sendo assim, haveria redundância ou duplicidade das informações aqui apresentadas, deixando o texto desnecessariamente extenso.

A. Atribuição das Variáveis Auxiliares

Serão utilizados algumas variáveis de ambiente UNIX, cujo propósito é simplificar a execução do procedimento, essas variáveis serão denominadas ou apelidada neste artigo como VARIAVEIS AUXILIARES, posto isto, sempre que mencionado o termo VARIAVEIS AUXILIARES, este refere-se as variáveis de ambiente UNIX que serão usadas no transcorrer do procedimento do qual almeja a descomplexificação das ações a serem realizadas.

• VARIAVEIS AUXILIARES = variáveis de ambiente unix

A fim de oferecer uma explanação detalhada do processo, será mostrado cada step da execução de atribuição das VARIAVEIS AUXILIARES e seus desdobramentos, contudo, também será demostrado e disponibilizado para download alguns scripts que farão de forma automatizada esta parte do procedimento.

##### ATRIBUICAO VARIAVEIS AUXILIARES - MANUALMENTE 
##### Usuário UNIX = ROOT

# unset : environment variables
unset ORACLE_SID ; unset ORACLE_HOME ; unset GRID_HOME

## HOMEs GI e RDBMS
export ORACLE_HOME_RDBMS=/u01/app/12.2/oracle/db1
export ORACLE_HOME_GI=/u00/app/12.2.0/grid

## User owner GI e RDBMS
export USER_RDBMS=$(/bin/ls -la $ORACLE_HOME_RDBMS/bin/oracle | awk -F" " {'print$3'})
export USER_GI=$(/bin/ls -la $ORACLE_HOME_GI/bin/oracle | awk -F" " {'print$3'})

## LD_LIBRARY_PATH
## RDBMS, GI and OS
export LD_LIBRARY_PATH=$ORACLE_HOME_RDBMS/lib32:$ORACLE_HOME_RDBMS/lib:$ORACLE_HOME_GI/lib32:
$ORACLE_HOME_GI/lib:/lib:/usr/lib:/usr/local/lib:/lib64:/usr/lib64:/usr/local/lib64

			

[root@DBAFurushima01 ~]# unset ORACLE_SID ; unset ORACLE_HOME ; unset GRID_HOME
[root@DBAFurushima01 ~]#
[root@DBAFurushima01 ~]# export ORACLE_HOME_RDBMS=/u01/app/12.2/oracle/db1
[root@DBAFurushima01 ~]# export ORACLE_HOME_GI=/u00/app/12.2.0/grid
[root@DBAFurushima01 ~]#
[root@DBAFurushima01 ~]# export USER_RDBMS=$(/bin/ls -la $ORACLE_HOME_RDBMS/bin/oracle | 
awk -F" " {'print$3'})
[root@DBAFurushima01 ~]# export USER_GI=$(/bin/ls -la $ORACLE_HOME_GI/bin/oracle | awk -F" " 
{'print$3'})
[root@DBAFurushima01 ~]#
[root@DBAFurushima01 ~]# export LD_LIBRARY_PATH=$ORACLE_HOME_RDBMS/lib32:$ORACLE_HOME_RDBMS/
lib:$ORACLE_HOME_GI/lib32:$ORACLE_HOME_GI/lib:/lib:/usr/lib:/usr/local/lib:/lib64:/usr
/lib64:/usr/local/lib64
[root@DBAFurushima01 ~]#
			

Finalizado todos os passos descritos, é necessário validar se as variáveis auxiliares, foram devidamente atribuídas, isto é, com seus respectivos valores corretos, utilizando-se do comando abaixo, execute essa validação:

echo -e "ORACLE_HOME_RDBMS = $ORACLE_HOME_RDBMS\nORACLE_HOME_GI = 
$ORACLE_HOME_GI\nSTAGE_RU = $STAGE_RU"


[root@DBAFurushima01 ~]# echo -e "ORACLE_HOME_RDBMS = $ORACLE_HOME_RDBMS\nORACLE_HOME_GI = 
$ORACLE_HOME_GI\nSTAGE_RU = $STAGE_RU"
ORACLE_HOME_RDBMS = /u01/app/12.2/oracle/db1
ORACLE_HOME_GI = /u00/app/12.2.0/grid
STAGE_RU = /mnt/stage/RU

			

NENHUMA DAS VARIAVEIS AUXILIARES, pode conter valor nulo, caso isso ocorra, atribua seu respectivo valor manualmente, veja um exemplo:

[root@DBAFurushima01 ~]#
[root@DBAFurushima01 ~]# echo -e "ORACLE_HOME_RDBMS = $ORACLE_HOME_RDBMS\nORACLE_HOME_GI = 
$ORACLE_HOME_GI\nSTAGE_RU = $STAGE_RU"
ORACLE_HOME_RDBMS = /u01/app/12.2/oracle/db1
ORACLE_HOME_GI = /u00/app/12.2.0/grid
STAGE_RU =
[root@DBAFurushima01 ~]#
[root@DBAFurushima01 ~]#
[root@DBAFurushima01 ~]# echo $STAGE_RU

[root@DBAFurushima01 ~]#
[root@DBAFurushima01 ~]# export STAGE_RU=/mnt/stage/RU
[root@DBAFurushima01 ~]#
[root@DBAFurushima01 ~]# echo $STAGE_RU
/mnt/stage/RU
[root@DBAFurushima01 ~]#
[root@DBAFurushima01 ~]#
[root@DBAFurushima01 ~]# echo -e "ORACLE_HOME_RDBMS = $ORACLE_HOME_RDBMS\nORACLE_HOME_GI = 
$ORACLE_HOME_GI\nSTAGE_RU = $STAGE_RU"
ORACLE_HOME_RDBMS = /u01/app/12.2/oracle/db1
ORACLE_HOME_GI = /u00/app/12.2.0/grid
STAGE_RU = /mnt/stage/RU
[root@DBAFurushima01 ~]#
[root@DBAFurushima01 ~]#
			

Salve as variáveis auxiliares um arquivo para posterior uso no decorrer do procedimento, veja o exemplo abaixo:

env  | egrep -i "ORACLE_HOME_RDBMS=|USER_RDBMS=|ORACLE_HOME_GI=|USER_GI=|STAGE_RU=|LD_LIBRARY_PATH=" | sort | tee /tmp/oravar


[root@DBAFurushima01 ~]#
[root@DBAFurushima01 ~]#
[root@DBAFurushima01 ~]# env  | egrep -i "ORACLE_HOME_RDBMS=|USER_RDBMS=|ORACLE_HOME_GI=
|USER_GI=|STAGE_RU=|LD_LIBRARY_PATH=" | sort | tee /tmp/oravar
LD_LIBRARY_PATH=/u01/app/12.2/oracle/db1/lib32:/u01/app/12.2/oracle/db1/lib:/u00/app/
12.2.0/grid/lib32:/u00/app/12.2.0/grid/lib:/lib:/usr/lib:/usr/local/lib:/lib64:/usr/
lib64:/usr/local/lib64
ORACLE_HOME_GI=/u00/app/12.2.0/grid
ORACLE_HOME_RDBMS=/u01/app/12.2/oracle/db1
STAGE_RU=/mnt/stage/RU
USER_GI=oracle
USER_RDBMS=oracle
[root@DBAFurushima01 ~]#
[root@DBAFurushima01 ~]#
[root@DBAFurushima01 ~]# ls -la /tmp/oravar
-rw-r--r--. 1 root root 327 May 30 20:39 /tmp/oravar
[root@DBAFurushima01 ~]#
[root@DBAFurushima01 ~]# cat /tmp/oravar
LD_LIBRARY_PATH=/u01/app/12.2/oracle/db1/lib32:/u01/app/12.2/oracle/db1/lib:/u00/app/
12.2.0/grid/lib32:/u00/app/12.2.0/grid/lib:/lib:/usr/lib:/usr/local/lib:/lib64:/usr/
lib64:/usr/local/lib64
ORACLE_HOME_GI=/u00/app/12.2.0/grid
ORACLE_HOME_RDBMS=/u01/app/12.2/oracle/db1
STAGE_RU=/mnt/stage/RU
USER_GI=oracle
USER_RDBMS=oracle
[root@DBAFurushima01 ~]#
[root@DBAFurushima01 ~]#

			

B. Upgrade OPatch

Após eleição, criação da área de stage e atribuição das variáveis auxiliares (como mostrado no tópico anterior), é necessário atualizar o OPatch oriundos dos binários RDBMS (DATABASE RDBMS) e GI (Grid Infrastructure - GI). Na sequência, é mostrado o step-by-step da atualização (upgrade) do OPatch para o RDBMS e GI :

ATUALIZANDO A VERSAO OPATCH RDBMS

export USR_GRP_RDBMS=$(echo $(ls -la $ORACLE_HOME_RDBMS/OPatch  | grep -i "opatch.pl" | 
awk -F" " {'print$3":"$4'}))
echo $USR_GRP_RDBMS
mv -v $ORACLE_HOME_RDBMS/OPatch  $ORACLE_HOME_RDBMS/OPatch.backup.old.$
(date "+%Y.%m.%d-%H.%M.%S")
ls -d $ORACLE_HOME_RDBMS/OPatch*
cp -vp $STAGE_RU/p6880880_122010_Linux-x86-64.zip   $ORACLE_HOME_RDBMS/
ls -d $ORACLE_HOME_RDBMS/p6880880_122010_Linux-x86-64.zip
unzip  -q $ORACLE_HOME_RDBMS/p6880880_122010_Linux-x86-64.zip -d  $ORACLE_HOME_RDBMS
ls -dl $ORACLE_HOME_RDBMS/OPatch*
chown  -R $USR_GRP_RDBMS $ORACLE_HOME_RDBMS/OPatch ; chmod -R 775 $ORACLE_HOME_RDBMS/OPatch
ls  --file-type -l  $ORACLE_HOME_RDBMS/OPatch | awk -F" " {'print$3"."$4'} | 
grep -i [a-z] | uniq
			

#######  
#######  Oracle Database (RDBMS) : 12.2.0.1.0 - Enterprise Edition
#######  Mova o diretorio OPatch, criando um backup referente a versão antiga.
#######  Copie o binario p6880880_122010_Linux-x86-64.zip para seus respectivos ORACLE_HOME
#######  Atualize o OPatch
#######  Ajuste o permissionamento
#######  Usuário UNIX = ROOT
#######
[root@DBAFurushima01 ~]# sudo -E su $USER_RDBMS -c '$ORACLE_HOME_RDBMS/OPatch/opatch version'
OPatch Version: 12.2.0.1.6

OPatch succeeded.  
[root@DBAFurushima01 ~]# 
[root@DBAFurushima01 ~]# 
[root@DBAFurushima01 ~]# 
[root@DBAFurushima01 ~]# 
[root@DBAFurushima01 ~]# 
[root@DBAFurushima01 ~]# export USR_GRP_RDBMS=$(echo $(ls -la $ORACLE_HOME_RDBMS/OPatch  | 
grep -i "opatch.pl" | awk -F" " {'print$3":"$4'}))
[root@DBAFurushima01 ~]# echo $USR_GRP_RDBMS
oracle:oinstall
[root@DBAFurushima01 ~]# mv -v $ORACLE_HOME_RDBMS/OPatch  
$ORACLE_HOME_RDBMS/OPatch.backup.old.$(date "+%Y.%m.%d-%H.%M.%S")
'/u01/app/12.2/oracle/db1/OPatch' -> 
'/u01/app/12.2/oracle/db1/OPatch.backup.old.2019.05.30-20.59.49'
[root@DBAFurushima01 ~]#
[root@DBAFurushima01 ~]# ls -d $ORACLE_HOME_RDBMS/OPatch*
/u01/app/12.2/oracle/db1/OPatch.backup.old.2019.05.30-20.59.49
[root@DBAFurushima01 ~]#
[root@DBAFurushima01 ~]#
[root@DBAFurushima01 ~]# 
[root@DBAFurushima01 ~]# cp -vp $STAGE_RU/p6880880_122010_Linux-x86-64.zip   
$ORACLE_HOME_RDBMS/
'/mnt/stage/RU/p6880880_122010_Linux-x86-64.zip' -> 
'/u01/app/12.2/oracle/db1/p6880880_122010_Linux-x86-64.zip'
[root@DBAFurushima01 ~]# 
[root@DBAFurushima01 ~]# ls -d $ORACLE_HOME_RDBMS/p6880880_122010_Linux-x86-64.zip
/u01/app/12.2/oracle/db1/p6880880_122010_Linux-x86-64.zip
[root@DBAFurushima01 ~]# 
[root@DBAFurushima01 ~]# unzip  -q $ORACLE_HOME_RDBMS/p6880880_122010_Linux-x86-64.zip -d  
$ORACLE_HOME_RDBMS
[root@DBAFurushima01 ~]# 
[root@DBAFurushima01 ~]# ls -dl $ORACLE_HOME_RDBMS/OPatch*
drwxrwxr-x. 14 oracle oinstall 4096 Apr 12 04:57 /u01/app/12.2/oracle/db1/OPatch
drwxr-xr-x. 12 oracle oinstall 4096 May 28 17:02 
/u01/app/12.2/oracle/db1/OPatch.backup.old.2019.05.30-20.59.49
[root@DBAFurushima01 ~]# 
[root@DBAFurushima01 ~]# chown  -R $USR_GRP_RDBMS $ORACLE_HOME_RDBMS/OPatch ; chmod -R 775 
$ORACLE_HOME_RDBMS/OPatch
[root@DBAFurushima01 ~]# 
[root@DBAFurushima01 ~]# ls  --file-type -l  $ORACLE_HOME_RDBMS/OPatch | awk -F" " 
{'print$3"."$4'} | grep -i [a-z] | uniq
oracle.oinstall
[root@DBAFurushima01 ~]# 
[root@DBAFurushima01 ~]# 
[root@DBAFurushima01 ~]# 
[root@DBAFurushima01 ~]# 
[root@DBAFurushima01 ~]# 
[root@DBAFurushima01 ~]# sudo -E su $USER_RDBMS -c '$ORACLE_HOME_RDBMS/OPatch/opatch version'
OPatch Version: 12.2.0.1.17

OPatch succeeded.
[root@DBAFurushima01 ~]# 
[root@DBAFurushima01 ~]#
			

[root@DBAFurushima01 ~]#
[root@DBAFurushima01 ~]# whoami
root
[root@DBAFurushima01 ~]# cd $ORACLE_HOME_RDBMS/OPatch/
[root@DBAFurushima01 OPatch]# pwd
/u01/app/12.2/oracle/db1/OPatch
[root@DBAFurushima01 OPatch]# ./opatch lspatches
The user is root. OPatch cannot continue if the user is root.

OPatch failed with error code 255
[root@DBAFurushima01 OPatch]#
			

[oracle@DBAFurushima01 ~]$
[oracle@DBAFurushima01 ~]$ whoami
oracle
[oracle@DBAFurushima01 ~]$ cd $ORACLE_HOME_RDBMS/OPatch/
[oracle@DBAFurushima01 OPatch]$ pwd
/u01/app/12.2/oracle/db1/OPatch
[oracle@DBAFurushima01 OPatch]$ ./opatch lspatches
There are no Interim patches installed in this Oracle Home "/u01/app/12.2/oracle/db1".

OPatch succeeded.
[oracle@DBAFurushima01 OPatch]$
			

[root@DBAFurushima01 ~]# whoami
root
[root@DBAFurushima01 ~]# sudo -E su oracle -c 'whoami'
oracle
[root@DBAFurushima01 ~]# whoami
root
			

ATUALIZANDO A VERSAO OPATCH GI

#######  
#######  Oracle Grid Infrastructure (GI) : 12.2.0.1.0 - Enterprise Edition
#######  Mova o diretorio OPatch, criando um backup referente a versão antiga.
#######  Copie o binario p6880880_122010_Linux-x86-64.zip para seus respectivos ORACLE_HOME
#######  Atualize o OPatch
#######  Ajuste o permissionamento
#######  Usuário UNIX = ROOT
#######

sudo -E su $USER_GI -c '$ORACLE_HOME_GI/OPatch/opatch version'
export USR_GRP_GI=$(echo $(ls -la $ORACLE_HOME_GI/OPatch  | grep -i "opatch.pl" | awk -F" " 
{'print$3":"$4'}))
echo $USR_GRP_GI
mv -v $ORACLE_HOME_GI/OPatch  $ORACLE_HOME_GI/OPatch.backup.old.$(date "+%Y.%m.%d-%H.%M.%S")
ls -d $ORACLE_HOME_GI/OPatch*
cp -vp $STAGE_RU/p6880880_122010_Linux-x86-64.zip   $ORACLE_HOME_GI/
ls -d $ORACLE_HOME_GI/p6880880_122010_Linux-x86-64.zip
unzip  -q $ORACLE_HOME_GI/p6880880_122010_Linux-x86-64.zip -d  $ORACLE_HOME_GI
ls -dl $ORACLE_HOME_GI/OPatch*
chown  -R $USR_GRP_GI $ORACLE_HOME_GI/OPatch ; chmod -R 775 $ORACLE_HOME_GI/OPatch
ls  --file-type -l  $ORACLE_HOME_GI/OPatch  | awk -F" " {'print$3"."$4'} | grep -i [a-z] | uniq
sudo -E su $USER_GI -c '$ORACLE_HOME_GI/OPatch/opatch version'
			

[root@DBAFurushima01 ~]#
[root@DBAFurushima01 ~]# sudo -E su $USER_GI -c '$ORACLE_HOME_GI/OPatch/opatch version'
OPatch Version: 12.2.0.1.6

OPatch succeeded.
[root@DBAFurushima01 ~]#
[root@DBAFurushima01 ~]#
[root@DBAFurushima01 ~]# export USR_GRP_GI=$(echo $(ls -la $ORACLE_HOME_GI/OPatch  | 
grep -i "opatch.pl" | awk -F" " {'print$3":"$4'}))
[root@DBAFurushima01 ~]# echo $USR_GRP_GI
oracle:oinstall
[root@DBAFurushima01 ~]#
[root@DBAFurushima01 ~]# mv -v $ORACLE_HOME_GI/OPatch  
$ORACLE_HOME_GI/OPatch.backup.old.$(date "+%Y.%m.%d-%H.%M.%S")
'/u00/app/12.2.0/grid/OPatch' -> '/u00/app/12.2.0/grid/OPatch.backup.old.2019.05.30-22.12.46'
[root@DBAFurushima01 ~]# ls -d $ORACLE_HOME_GI/OPatch*
/u00/app/12.2.0/grid/OPatch.backup.old.2019.05.30-22.12.46
[root@DBAFurushima01 ~]#
[root@DBAFurushima01 ~]# cp -vp $STAGE_RU/p6880880_122010_Linux-x86-64.zip   $ORACLE_HOME_GI/
'/mnt/stage/RU/p6880880_122010_Linux-x86-64.zip' -> 
'/u00/app/12.2.0/grid/p6880880_122010_Linux-x86-64.zip'
[root@DBAFurushima01 ~]# ls -d $ORACLE_HOME_GI/p6880880_122010_Linux-x86-64.zip
/u00/app/12.2.0/grid/p6880880_122010_Linux-x86-64.zip
[root@DBAFurushima01 ~]#
[root@DBAFurushima01 ~]# unzip  -q $ORACLE_HOME_GI/p6880880_122010_Linux-x86-64.zip -d  
$ORACLE_HOME_GI
[root@DBAFurushima01 ~]# ls -dl $ORACLE_HOME_GI/OPatch*
drwxr-x---. 14 root   root     4096 Apr 12 04:57 /u00/app/12.2.0/grid/OPatch
drwxr-xr-x. 12 oracle oinstall 4096 Jan 26  2017 
/u00/app/12.2.0/grid/OPatch.backup.old.2019.05.30-22.12.46
[root@DBAFurushima01 ~]#
[root@DBAFurushima01 ~]# chown  -R $USR_GRP_GI $ORACLE_HOME_GI/OPatch ; chmod -R 775 
$ORACLE_HOME_GI/OPatch
[root@DBAFurushima01 ~]# ls  --file-type -l  $ORACLE_HOME_GI/OPatch  | awk -F" " 
{'print$3"."$4'} | grep -i [a-z] | uniq
oracle.oinstall
[root@DBAFurushima01 ~]#
[root@DBAFurushima01 ~]# sudo -E su $USER_GI -c '$ORACLE_HOME_GI/OPatch/opatch version'
OPatch Version: 12.2.0.1.17

OPatch succeeded.
[root@DBAFurushima01 ~]#
[root@DBAFurushima01 ~]#
			

NÃO AVANCE PARA OS PROXIMOS STEPS, SEM REALIZAR OS MESMO PROCEDIMENTOS NOS OUTROS NODES DO ORACLE RAC.

OBS. : Repita os mesmos passos, nos demais nodes do ORACLE RAC, antes de prosseguir as próximas fases do procedimento.

OBS.2 : Caso seu ambiente não se tratar de um ORACLE RAC, desconsidere essa informação.

Resumo das ações executadas até o momento:

1. Introdução as definições pertinentes aos conceitos teóricos que tange OPatch.
2. Estrutura do utilitário OPatch.
3. Atribuição das Variáveis Auxiliares.
4. Upgrade OPatch (GI e RDBMS)

Passo 3. Aplicação do RU - RELEASE UPDATE 12.2.0.1.190416

Após executado, os procedimento descritos anteriormente, em TODOS OS NODES QUE COMPOEM O ORACLE RAC, o próximo passo é submeter os binários GI e RDBMS a aplicação do RELEASE UPDATE (RU), no exemplo demostrado neste artigo é utilizado a versão 190416 de abril/2019 (Patch = 29301687), é importante ressaltar que o "modus operandi" do processo de aplicação do RELEASE UPDATE – RU (PATCH) em relação a versões antecedentes (anteriores) ou futura a esta utilizada neste artigo (190416 de abril/2019 - 29301687) é semelhante, ou seja, o conceito geral deste procedimento pode ser usado como base para aplicações de outra versões de RELEASE UPDATE (antigas e/ou futuras).

Antes de submeter os binários a aplicação do patch é necessário estabelecer algumas verificações de pré-requisitos, tais validações devem ser feitas com usuário owner do software oracle (GI e RDBMS), que no caso deste cenário do artigo trata-se do usuário "oracle", porem é fundamental manter as variáveis de ambiente do usuário root (variáveis auxiliares, citadas anteriormente neste artigo), afim de evitar desentendimentos/equívocos na transição ou troca entre os usuários oracle e root, bem como a manutenção das variáveis de ambiente necessárias para execução deste procedimento, utilizaremos a chamada “sudo” para execução dos comandos em um único contexto de execução (sessão), sendo assim, os comandos que devem ser executados no contexto do usuário UNIX oracle serão feitos via sudo com usuário root. Abaixo é demonstrado um exemplo desta manutenção do contexto de sessão:

Usuário corrente root, executando comando "whoami" em sua sessão (contexto).

[root@DBAFurushima01 ~]# whoami
root
			

Usuário corrente root, executando comando "whoami", com usuário oracle, utilizando o mesmo contexto (sessão). Neste caso não é necessário trocar de sessão para utilizar o usuário oracle, bem como as variáveis de ambiente são mantidas, referente ao contexto root (a qual possui as variáveis auxiliares).

[root@DBAFurushima01 ~]# sudo -E su oracle -c 'whoami'
oracle 
			

sudo -E su oracle -c 'whoami'

sudo: Execução de comandos como outro usuário.

-E: Preserva as variáveis de ambiente do atual contexto, ou seja, indica que o executor aspira preservar suas variáveis de ambiente existentes em sua sessão.

"su oracle": Comando para troca de usuário, sem carregamento das variáveis de ambiente do usuário destino.

-c: Comando a ser executado no shell corrente.

Conforme descrito anteriormente, é necessário estabelecer algumas verificações de pré-requisitos, que compreende dois pontos básicos

A. Espaço necessário no filesystem a qual os binários estão alojados (instalados).

• Confirmação se há espaço livre suficiente disponível no filesystem a qual o ORACLE_HOME, está alojado (instalado).

ls -dl  $STAGE_RU/oracle/*[0-9]/*[0-9] | awk -F" " {'print$9'} | 
tee $STAGE_RU/oracle/log/patch_list_ru_gi_and_rdbms_home.txt
sudo -E su oracle -c '$ORACLE_HOME_RDBMS/OPatch/opatch prereq CheckSystemSpace 
-phBaseFile $STAGE_RU/oracle/log/patch_list_ru_gi_and_rdbms_home.txt'
sudo -E su oracle -c '$ORACLE_HOME_GI/OPatch/opatch prereq CheckSystemSpace -phBaseFile 
$STAGE_RU/oracle/log/patch_list_ru_gi_and_rdbms_home.txt'

[root@DBAFurushima01 ~]#
[root@DBAFurushima01 ~]# ls -dl  $STAGE_RU/oracle/*[0-9]/*[0-9] | awk -F" " {'print$9'} | 
tee $STAGE_RU/oracle/log/patch_list_ru_gi_and_rdbms_home.txt
/mnt/stage/RU/oracle/29301687/26839277
/mnt/stage/RU/oracle/29301687/28566910
/mnt/stage/RU/oracle/29301687/29301676
/mnt/stage/RU/oracle/29301687/29314339
/mnt/stage/RU/oracle/29301687/29314424
[root@DBAFurushima01 ~]#
[root@DBAFurushima01 ~]# sudo -E su oracle -c '$ORACLE_HOME_RDBMS/OPatch/opatch prereq 
CheckSystemSpace -phBaseFile $STAGE_RU/oracle/log/patch_list_ru_gi_and_rdbms_home.txt'
Oracle Interim Patch Installer version 12.2.0.1.17
Copyright (c) 2019, Oracle Corporation.  All rights reserved.

PREREQ session

Oracle Home       : /u01/app/12.2/oracle/db1
Central Inventory : /u00/app/oraInventory
   from           : /u01/app/12.2/oracle/db1/oraInst.loc
OPatch version    : 12.2.0.1.17
OUI version       : 12.2.0.1.4
Log file location : /u01/app/12.2/oracle/db1/cfgtoollogs/opatch/
opatch2019-05-30_22-45-45PM_1.log

Invoking prereq "checksystemspace"

Prereq "checkSystemSpace" passed.

OPatch succeeded.
[root@DBAFurushima01 ~]#
[root@DBAFurushima01 ~]# sudo -E su oracle -c '$ORACLE_HOME_GI/OPatch/opatch prereq 
CheckSystemSpace -phBaseFile $STAGE_RU/oracle/log/patch_list_ru_gi_and_rdbms_home.txt'
Oracle Interim Patch Installer version 12.2.0.1.17
Copyright (c) 2019, Oracle Corporation.  All rights reserved.

PREREQ session

Oracle Home       : /u00/app/12.2.0/grid
Central Inventory : /u00/app/oraInventory
   from           : /u00/app/12.2.0/grid/oraInst.loc
OPatch version    : 12.2.0.1.17
OUI version       : 12.2.0.1.4
Log file location : /u00/app/12.2.0/grid/cfgtoollogs/opatch/opatch2019-05-30_22-45-59PM_1.log

Invoking prereq "checksystemspace"

Prereq "checkSystemSpace" passed.

OPatch succeeded.
[root@DBAFurushima01 ~]#
[root@DBAFurushima01 ~]#
			

B. Conflito entre os diversos patchs

Abrange uma validação de conflitos entre os patchs a serem aplicados, bem como o cruzamento de informações para examinar possíveis conflitos entre os patchs existentes (caso houver) e os que irão ser aplicados.

• Confirmação se quaisquer patches atualmente instalados (caso houver), entrarão em conflito com o patch que está sendo aplicado.
• Esta validação deve ser feita individualmente para cada ORACLE_HOME existente (GI e/ou RDBMS).

## GI - Grid Infrastructure
## CheckConflictAgainstOHWithDetail
for b in $( cat $STAGE_RU/oracle/log/patch_list_ru_gi_and_rdbms_home.txt ) ; do
export patch_id_gi=$b
echo $patch_id_gi
sudo -E su oracle -c '$ORACLE_HOME_GI/OPatch/opatch prereq CheckConflictAgainstOHWithDetail 
-phBaseDir $patch_id_gi'
echo '' ; echo ''
done
			

## Database RDBMS
## CheckConflictAgainstOHWithDetail
for a in $( cat $STAGE_RU/oracle/log/patch_list_ru_gi_and_rdbms_home.txt ) ; do
export patch_id_rdbms=$a
echo $patch_id_rdbms
sudo -E su oracle -c '$ORACLE_HOME_RDBMS/OPatch/opatch prereq 
CheckConflictAgainstOHWithDetail -phBaseDir $patch_id_rdbms'
echo '' ; echo ''
done
			

APLICANDO RU: G

######### GI
######### APPLY
export USER=$USER_GI
export ORACLE_HOME=$ORACLE_HOME_GI
export PATH=$ORACLE_HOME/OPatch:$ORACLE_HOME/OPatch/ocm/bin:$ORACLE_HOME/bin:$PATH
export RU_PATH=$(echo $STAGE_RU/oracle/*[0-9]*)
cd $RU_PATH
$ORACLE_HOME/OPatch/opatchauto apply $RU_PATH -analyze -oh $ORACLE_HOME
$ORACLE_HOME/OPatch/opatchauto apply $RU_PATH -oh $ORACLE_HOME
			

APLICANDO RU: RDBMS

######### RDBMS
######### APPLY
export USER=$USER_RDBMS
export ORACLE_HOME=$ORACLE_HOME_RDBMS
export PATH=$ORACLE_HOME/OPatch:$ORACLE_HOME/OPatch/ocm/bin:$ORACLE_HOME/bin:$PATH
export RU_PATH=$(echo $STAGE_RU/oracle/*[0-9]*)
cd $RU_PATH
$ORACLE_HOME/OPatch/opatchauto apply $RU_PATH -analyze -oh $ORACLE_HOME
$ORACLE_HOME/OPatch/opatchauto apply $RU_PATH -oh $ORACLE_HOME
			

ROLLBACK RU: GI

######### GI
######### ROLLBACK
export USER=$USER_GI
export ORACLE_HOME=$ORACLE_HOME_GI
export PATH=$ORACLE_HOME/OPatch:$ORACLE_HOME/OPatch/ocm/bin:$ORACLE_HOME/bin:$PATH
export RU_PATH=$(echo $STAGE_RU/oracle/*[0-9]*)
cd $RU_PATH
$ORACLE_HOME/OPatch/opatchauto rollback  $RU_PATH -analyze -oh $ORACLE_HOME
$ORACLE_HOME/OPatch/opatchauto rollback  $RU_PATH -oh $ORACLE_HOME
			

ROLLBACK RU: RDBMS

NÃO AVANCE PARA OS PROXIMOS STEPS, SEM REALIZAR OS MESMO PROCEDIMENTOS NOS OUTROS NODES DO ORACLE RAC.

OBS.: Repita os mesmos passos, nos demais nodes do ORACLE RAC, antes de prosseguir as próximas fases do procedimento.

OBS.2 : Caso seu ambiente não se tratar de um ORACLE RAC, desconsidere essa informação.

Resumo das ações executadas até o momento:

1. Uso do utilitário sudo, para manutenção do contexto e variáveis de ambiente.
2. Pre-req opatch CheckSystemSpace (GI e RDBMS).
3. e-req opatch CheckConflictAgainstOHWithDetail (GI e RDBMS).
4. Aplicação (Apply) RELEASE UPDATE (RU), nos binarios GI e RDBMS
5. Reversão (Rollback) RELEASE UPDATE (RU), nos binarios GI e RDBMS.

Passo 4. Validação Final

Finalizado todos os passos anteriores, recomenda-se executar uma validação final, como é mostrado abaixo:

• O script opatch_summary.sh, disponível no link github, abaixo, nos dá uma visão simples e sumarizada dos patchs existentes no ORACLE_HOME:
  • https://github.com/wayneadamsconsulting/oracle-opatch_summary

GI

export ORACLE_HOME=/u00/app/12.2.0/grid
export PATH=$ORACLE_HOME/OPatch:$ORACLE_HOME/OPatch/ocm/bin:$ORACLE_HOME/bin:$PATH
echo $ORACLE_HOME
./opatch_summary.sh
			

RDBMS

export ORACLE_HOME=/u01/app/12.2/oracle/db1
export PATH=$ORACLE_HOME/OPatch:$ORACLE_HOME/OPatch/ocm/bin:$ORACLE_HOME/bin:$PATH
echo $ORACLE_HOME
./opatch_summary.sh
			

• https://mikedietrichde.com/wp-content/scripts/12c/check_patches.sql

WITH a 
     AS (SELECT dbms_qopatch.get_opatch_lsinventory patch_output 
         FROM   dual) 
SELECT x.patch_id, 
       bundle_series, 
       s.description, 
To_char(To_date(Regexp_substr(s.description, '\.[0-9]{6}'), '.YYMMDD'), 'DD-MON-YYYY') 
patch_date 
FROM   a, 
       XMLTABLE('InventoryInstance/patches/*' passing a.patch_output COLUMNS 
       patch_id 
       NUMBER path 'patchID', patch_uid NUMBER path 'uniquePatchID', description 
       VARCHAR2(80) path 'patchDescription', rollbackable VARCHAR2(8) path 
       'rollbackable' ) x, 
       dba_registry_sqlpatch s 
WHERE  x.patch_id = s.patch_id 
       AND x.patch_uid = s.patch_uid 
ORDER  BY patch_date;
			

• https://www.dba-resources.com/oracle/obtaining-database-psu-history-from-sql/

NÃO AVANCE PARA OS PROXIMOS STEPS, SEM REALIZAR OS MESMO PROCEDIMENTOS NOS OUTROS NODES DO ORACLE RAC.

OBS. : Repita os mesmos passos, nos demais nodes do ORACLE RAC, antes de prosseguir as próximas fases do procedimento.

OBS.2 : Caso seu ambiente não se tratar de um ORACLE RAC, desconsidere essa informação.

Resumo das ações executadas até o momento:

1. Validação dos patchs aplicados via script opatch_summary.sh nos binários GI e RDBMS.
2. Validação datapatch consultando sys.registry$history e DBA_REGISTRY_SQLPATCH.
3. Validação dos patchs aplicados no binário RDBMS via script check_patches.sql.

• Outras Referências para leitura complementar ao artigo:
• http://dbaparadise.com/2017/07/all-you-need-to-know-about-local-oracle-inventory/
• https://docs.oracle.com/cd/E24628_01/doc.121/e39376/opatch_overview.htm#OPTCH350
• https://nenadnoveljic.com/blog/simultaneous-patching-not-possible-datapatch/
• https://mikedietrichde.com/2017/10/24/differences-psu-bp-ru-rur/

• Outras Referências para leitura complementar referente ao tema OPatch :
• Grid Infrastructure Out of Place ( OOP ) Patching using opatchauto (Doc ID 2419319.1)
• Troubleshooting Assistant:12c Datapatch Issues (Doc ID 2335899.2)
• Datapatch: Database 12c or later Post Patch SQL Automation (Doc ID 1585822.1)
• http://www.ludovicocaldara.net/dba/gi18c-patching-part1/
• http://www.ludovicocaldara.net/dba/dbms_qopatch-datapatch-rollback-apply-force/
• https://docs.oracle.com/cd/E24628_01/doc.121/e39376/opatch_bin.htm#OPTCH568

Carlos H. Y. Furushima é um especialista em banco de dados relacional, trabalhando como consultor de TI, atuando principalmente como o Oracle Database Administrator (DBA Oracle). Tem uma vasta experiência e conhecimento em "Performance, diagnosticand tuning", "High Availability", "Backup & Recovery" e "Exadata". Ele também está entusiasmado com sistema operacional Linux/Unix, onde contribui com o desenvolvimento do código do kernel Linux em parceria com a comunidade "GNU Linux", com criação e revisão de novas funcionalidades, melhorias e correções de bugs. Recentemente, Furushima divide seu tempo com consultoria especializada em banco de dados Oracle e estudos sobre "Oracle Internals", com o objetivo de descobrir e entender os benefícios do bancos de dados Oracle em plataforma Linux/Unix.

Este artigo foi revisto pela equipe de produtos Oracle e está em conformidade com as normas e práticas para o uso de produtos Oracle.