Thiago Castro | Data Platforms & Databases

Precisei movimentar um tablespace de um diskgroup com redundância no ASM EXTERNAL para um outro com redundância NORMAL. Abaixo vou descrever os passos que realizei no meu ambiente de homologação para testar. Bom, no meu caso o tablespace era bigfile e como tinha um tamanho de 34Tb,  então deixar o arquivo offline e então realizar o backup não era uma opção por conta do tempo de parada. Então fui na estratégia do backup as COPY com o RMAN e todos os dias ia fazendo o recover do arquivo de cópia. A vantagem de usar esse método é que posso criar um cópia do datafile (backup full) e ir adicionando as mudanças que foram feitas no arquivo original na minha cópia com o banco de dados online. Utilizei o bloco de comando no RMAN abaixo para a criação do arquivo de cópia, recover e backup incremental.  Executei esse bloco de comando todos os dias para deixar meu arquivo de cópia o mais próximo possível do arquivo original e no dia em que fosse realizar o procedimento em produção, o temp...

Durante o upgrade da versão 18c para 19c GI, quando estava executando o script rootupgrade.sh recebi um erro no passo 8 2020/07/22 08:47:13 CLSRSC-595: Executing upgrade step 1 of 18: 'UpgradeTFA'. 2020/07/22 08:47:13 CLSRSC-4015: Performing install or upgrade action for Oracle Trace File Analyzer (TFA) Collector. 2020/07/22 08:47:13 CLSRSC-595: Executing upgrade step 2 of 18: 'ValidateEnv'. 2020/07/22 08:47:14 CLSRSC-595: Executing upgrade step 3 of 18: 'GetOldConfig'. 2020/07/22 08:47:14 CLSRSC-464: Starting retrieval of the cluster configuration data 2020/07/22 08:47:19 CLSRSC-692: Checking whether CRS entities are ready for upgrade. This operation may take a few minutes. 2020/07/22 08:49:03 CLSRSC-4003: Successfully patched Oracle Trace File Analyzer (TFA) Collector. 2020/07/22 08:49:26 CLSRSC-693: CRS entities validation completed successfully. 2020/07/22 08:49:31 CLSRSC-465: Retrieval of the cluster configuration data has successfully completed. 2020/07/22...

Ao tentar aplicar o Patch 30899722 - GI Release Update 19.7.0.0.200414 me deparei com um erro durante a execução do Opatch no momento em que ele faz a checagem do espaço disponível. Na documentação da Oracle encontramos isso: Fiz o que foi pedido, criei o arquivo patch_list_gihome.txt e coloquei os caminhos listados, mas recebi o seguinte erro: [grid@teste ~]$ cat /tmp/patch_list_gihome. txt                                             /tmp/30899722/30869156 /tmp/30899722/30894985 /tmp/30899722/30869304 /tmp/30899722/ /tmp/30899722/30898856  [grid@teste ~]$ $ORACLE_HOME/OPatch/opatch prereq CheckSystemSpace -phBaseFile /tmp/patch_list_gihome.txt Oracle Interim Patch Installer version 12.2.0.1.17 Copyright (c) 2020, Oracle Corporation.  All rights reserved. PREREQ session Oracle Home       : /u01/app/19.3.0/grid Central...

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