Pular para o conteúdo principal

Upgrade Oracle Grid Infrastructure 18c -> 19c

Neste post vou descrever de uma forma direta o passo a passo do upgrade Oracle GI da versão 18 para 19. Tenho o GI rodando em um nó standalone. Abaixo detalho o nível de patch que estou antes de começar o upgrade.


[grid@myhost ~]$ crsctl query has releasepatch
Oracle Clusterware release patch level is [170989027] and the complete list of patches [27908644 27923415 28090523 28090553 28090557 28256701 29757256 ] have been applied on the local node. The release patch string is [18.7.0.0.0].

[grid@myhost grid]$ echo $ORACLE_HOME
/u01/app/18.3.0/grid


Bom, o primeiro passo é baixar o novo software que irá ser instalado.

Na documentação oficial, a Oracle recomenda baixar o utilitário ORAchk para verificar seu ambiente antes do upgrade o procedimento é descrito no doc 1457357.1 Neste post não vou descrevrer este procedimento por se tratar de um ambiente de testes, mas em produção é importante segui-lo.

Estou usando o usuário grid como dono do software GI e o usuário oracle como do software BD. Crie o caminho para seu novo GI e descompacte o arquivo dentro dele.

mkdir -p /u01/app/19.3.0.0/grid

cp LINUX.X64_193000_grid_home.zip /u01/app/19.3.0.0/grid
cd /u01/app/19.3.0.0/grid
unzip -q LINUX.X64_193000_grid_home.zip
rm LINUX.X64_193000_grid_home.zip



No home do GI 19, execute o ./gridSetup.sh

No passo de pré-requisitos, podemos ver que o upgrade depende da aplicação de um patch na versão 18c.


Então vamos aplicar o patch. Primeiro vamos baixar a versão mais nova do OPatch e em seguida realizar o download do  Patch 28553832

Aqui não vou entrar em detalhes de como atualizar o OPatch. Vou supor que o download foi feito e já está na ultima versão do OPatch. Agora vamos aplicar o patch necessário.

Descompacte o arquivo, realize o pre-check e aplique o patch. É importante ler o README do patch para saber o procedimento exato para o seu ambiente. No meu caso, apliquei no home do grid.


cd /tmp
unzip p28553832_183000OCWRU_Linux-x86-64.zip

[root@myhost 28553832]# /u01/app/18.3.0/grid/OPatch/opatchauto apply /tmp/28553832 -analyze

--------------------------------Summary--------------------------------
Analysis for applying patches has completed successfully:

Host:myhost
SIHA Home:/u01/app/18.3.0/grid
Version:18.0.0.0.0

==Following patches were SUCCESSFULLY analyzed to be applied:

Patch: /tmp/28553832/28553832
Log: /u01/app/18.3.0/grid/cfgtoollogs/opatchauto/core/opatch/opatch2020-06-23_17-51-55PM_1.log



Aplicando o patch.


[root@myhost lib]# /u01/app/18.3.0/grid/OPatch/opatchauto apply /tmp/28553832/ -oh /u01/app/18.3.0/grid/

--------------------------------Summary--------------------------------

Patching is completed successfully. Please find the summary as follows:

Host:myhost
SIHA Home:/u01/app/18.3.0/grid
Version:18.0.0.0.0
Summary:

==Following patches were SUCCESSFULLY applied:

Patch: /tmp/28553832/28553832
Log: /u01/app/18.3.0/grid/cfgtoollogs/opatchauto/core/opatch/opatch2020-06-25_18-09-28PM_1.log




Patch aplicado, agora vamos realizar o upgrade para o 19c.

Criei um arquivo com as variáveis de ambiente para a versão 19.


#!/bin/bash
export TMP=/tmp
export TMPDIR=$TMP
export ORACLE_HOSTNAME=myhost
export ORACLE_SID=+ASM
export ORACLE_BASE=/u01/app/grid
export ORACLE_HOME=/u01/app/19.3.0/grid
export ORACLE_SID=+ASM
export ORACLE_TERM=xterm
export PATH=/usr/sbin:$PATH
export PATH=$ORACLE_HOME/bin:$PATH
export LD_LIBRARY_PATH=$ORACLE_HOME/lib:/lib:/usr/lib
export CLASSPATH=$ORACLE_HOME/JRE:$ORACLE_HOME/jlib:$ORACLE_HOME/rdbms/jlib




Exporte as variáveis 19 e executer o gridSetup.


[grid@myhost ~]$ . .bash_profile19

[grid@myhost ~]$ /u01/app/19.3.0/grid/gridSetup.sh



Selecione a opção de Upgrade do Oracle GI




Na verificação de pré-requisitos, vemos que não temos mais o problema de pré-requisitos do patch.


Execute rootupgrade.sh e finalize o processo. Pronto temos nosso GI na versão 19c.




[root@myhost ~]# /u01/app/19.3.0/grid/rootupgrade.sh
Performing root user operation.
.
.
.
CRS-4664: Nó myhost retido com sucesso.
2020/06/25 20:47:48 CLSRSC-595: Executing upgrade step 9 of 12: 'CreateOHASD'.
2020/06/25 20:47:49 CLSRSC-595: Executing upgrade step 10 of 12: 'ConfigOHASD'.
2020/06/25 20:47:49 CLSRSC-329: Replacing Clusterware entries in file 'oracle-ohasd.service'
2020/06/25 20:49:34 CLSRSC-595: Executing upgrade step 11 of 12: 'UpgradeSIHA'.

myhost     2020/06/25 20:50:10     /u01/app/grid/crsdata/myhost/olr/backup_20200625_205010.olr     724960844

myhost     2019/09/12 22:21:39     /u01/app/18.3.0/grid/cdata/myhost/backup_20190912_222139.olr     70732493

myhost     2019/07/08 12:11:18     /u01/app/11.2.0/grid/cdata/myhost/backup_20190708_121118.olr     -
2020/06/25 20:50:10 CLSRSC-595: Executing upgrade step 12 of 12: 'InstallACFS'.
2020/06/25 20:53:12 CLSRSC-327: Successfully configured Oracle Restart for a standalone server






Após a atualização, consultamos novamente a versão do software e vemos que já estamos na versão desejada, 19c.


[grid@myhost ~]$ crsctl query has releasepatch
Oracle Clusterware release patch level is [724960844] and the complete list of patches [29401763 29517242 29517247 29585399 ] have been applied on the local node. The release patch string is [19.3.0.0.0].





Comentários

Anônimo disse…
Betway Casino in Thabasca, Alberta - Thakasino
Betway Casino offers a wide variety of online happyluke casino m88 games like blackjack, 제왕카지노 poker, roulette, and betway and betway.

Postagens mais visitadas deste blog

Configurando a política de retenção de backups no RMAN

                       Configurando a politica de reten çã o de backups no RMAN        O objetivo deste post é explicar como podemos configurar a reten çã o de backups na poderosa ferramenta de backup do bando de dados Oracle RMAN. Podemos configurar nossa pol í tica tendo por base dois tipos: janela de recupera çã o (recovery window) ou redundãncia (redundancy). Abaixo iremos abordar os dois tipos.       Para identificar qual dos dois tipos o RMAN está usando, use: RMAN> show retention policy; Política baseada em redundância CONFIGURE RETENTION POLICY TO REDUNDANCY 1; Política baseada em janela de recuperação CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 2 DAYS; ·        Política baseada em redund â ncia ( REDUNDANCY )       De uma maneira bem simples e objetiva, o par â metro REDUNDANCY especifica quantos backups full ou incremental level 0 de cada datafile o RMAN vai manter, os demais são considerados obsoletos. Veja o exemplo abaixo

Permissões necessárias para criar triggers no Oracle

Há pouco tempo passei por um problema durante a criação de uma trigger de LOGON na versão 12c do banco de dados Oracle. Estava com alguns problemas em uma aplicação que tinha uma trigger de Logon. A trigger em si era bem simples, vou por o código mais abaixo, o problema é que ela estava criada dentro do usuário SYSTEM. Provavelmente foi a maneira mais fácil e preguiçosa de criar o objeto, uma vez que o SYSTEM já possui todas as permissões necessárias para criação. Porém isso não uma boa prática. Então resolvi tirar do SYSTEM e jogar para o usuário dono dos objetos da aplicação. Quando fui tentar criar o objeto no SCHEMA dono dos objetos da aplicação, recebi um erro com falta de permissões: ORA-01031: insufficient privileges . O erro ocorreu porque estava esquecendo de conceder a role ADMINISTER DATABASE TRIGGER para o usuário. Em resumo, as permissões necessárias para criação de uma trigger: CREATE TRIGGER - para criar uma trigger no seu próprio esquema (SCHEMA) CREATE AN

ORA-01623 ORA-00312 - Removendo redo logs

Após realizar um restore de um ambiente de Oracle RAC para um single instance usando snapshot de storage, tentei recriar os redo logs recebi o seguinte erro durante a exclusão de um grupo de discos. SQL> alter database drop logfile group 2; ORA-01623: o log 2 é o log atual para a instância UOW (thread 1) - não é possível eliminar ORA-00312: thread 2 do log 1 on-line: '+DATA/UOW/ONLINELOG/group_2.1638.1051804433' ORA-00312: thread 2 do log 1 on-line: '+DATA/UOW/ONLINELOG/group_2.981.1051804433' O erro quer dizer que o grupo de redo pertence a outra thread. Quer dizer que ele pertence a outra instância do ambiente RAC. Como no meu caso não precisarei mais dela, basta usar o comando: SAL> alter database disable thread 2; Database altered.   Usei o SQL abaixo para gerar os comandos para excluir os redo logs SQL> select distinct 'alter database drop logfile group '||(group#)||';' from v$log where thread#=2; 'ALTERDATABASEDROPLOGFILEGROUP'||(G