[11.2.0.3.0 to 11.2.0.4.3] Upgrade release e aplicação de Patch Set Update (PSU) Introdução e instalaçao do Oracle PatchSet Full 11.2.0.4.0

Este artigo está dividido em duas partes: 

- Parte 1) Introdução e instalaçao do Oracle PatchSet Full 11.2.0.4.0 - Parte 2) Aplicação de Patch Set Update (PSU) 11.2.0.4.3

Introdução

Com a consolidação do Oracle Database 12c é natural o processo de descontinuidade da versão 11g, seja pela fim do “Premier Support” ou por tronar-se funcionalmente obsoleto devido aos surgimento de novas funcionalidades e melhorias de outras já existentes. Neste processo de transição 11g/12c é natural resistência ou precauções por parte do DBA, contudo é um caminho inevitável, não é novidade que muitas aplicações de terceiros ou de desenvolvimento próprio não estão totalmente homologadas ou adaptadas para versão 12c, enquanto essa situação não acontece é de extrama importância o DBA manter seu banco de dados na versão/release/PSU mais atual possível de pro-ativa, não espere aparecer um bug para atualizar seu ambiente.

Oracle PatchSet x PSU x CPU

Oracle PatchSet são os arquivos geralmente encontrados em formato zip que permitem a instalação de produtos Oracle em diferentes plataformas e arquiteturas computacionais. Pode-se citar como exemplo o Oracle Database PatchSet, um conjunto de arquivos em formato zip onde porta diferentes componentes que formam o Oracle Database. Os componentes encontrados no Oracle Database PatchSet Release 11.2.0.4 (11gR2) são:

Imagem retirada da nota oficial da oracle

platform = Linux , Windows , AIX , HP-UX , etc...

PSU (Patch Set Updates) são atualizações trimestrais de um determinando release, essas atualizações incluem fix para correção de bug e/ou novos tratamento de erros (ora-600 por exemplo). Um PSU é aplicado em um determinando release. Assim aplicação do PSU 3 do release 11.2.0.4 levo o Oracle ao versão 11.2.0.4.3 .

[Doc ID 756671.1]: Oracle Recommended Patches -- Oracle Database

CPU (Critical Patch Updates) são subconjuntos de um PSU (CPU está contido no PSU), ou seja, um conjunto de CPU forma um PSU, que por sua vez é consolidado e publicado trimestralmente no portal oficial da Oracle (MOS - My Oracle Support ou para os antigos METALINK). Conceitualmente um CPU (Critical Patch Updates), consiste em uma coleção de fix de segurança (security fixes) para os produtos da Oracle.

//www.oracle.com/technetwork/topics/security/cpujan2014-1972949.html [Doc ID 1594621.1]: Patch Set Update and Critical Patch Update January 2014 Availability Document

A atualização de versionamento do produto Oracle database 11gR2, onde o release origem é 11.2.0.3.0 e o release destino é 11.2.0.4.3, estão descrita abaixo em duas partes neste artigo.

Parte 1) Instalação do Oracle PatchSet Full 11.2.0.4.0

Nesta primeira parte é necessário uma nova instalação, usando o Oracle PatchSet 11.2.0.4.0 em uma máquina onde exista um Oracle release 11gR2 previamente instalado, neste caso o release existente é o 11.2.0.3.0. É importante ressaltar que essa nova instalação é um upgrade do "patch set release”, ou seja, o número 4 localizado na quarta casa da sequência de números do release number 11.2.0.4.0.

Segue abaixo as especificações de cada casa numérica, segundo a Oracle:

Outro detalhe importante é que um upgrade do "patch set release" é uma nova instalação do binário em uma localização de diretórios diferente dos binários já existente.

Exemplo: ORACLE_HOME RDBMS 11.2.0.3.0 está instalado em /oracle/app/product/11.2.0.3, ao executar o upgrade do "patch set release" para 11.2.0.4 (nova instalação usando o Oracle PatchSet 11.2.0.4.0) é importante preservar a instalação antiga, no caso os binários (arquivos) existente no diretório /oracle/app/product/11.2.0.3, que pertencem a instalação da versão 11.2.0.3.0, os novos binários (arquivos) oriundo da instalação do Oracle PatchSet 11.2.0.4.0, devem ser instalados em outra estrutura de diretório dentro de ORACLE_BASE, no caso /oracle/app/product/11.2.0.4 . No caso, temos duas estruturas de ORACLE_HOME distintas, são elas ORACLE_HOME RDBMS, que chamaremos no decorrer do texto de ORACLE_HOME e ORACLE_HOME GI (Grid Infrastructure), que chamaremos no decorrer do texto de GRID_HOME. Ambas as estruturas devem ser submetidas ao upgrade do "patch set release" (RDBMS e GI) é importante frizar que essa operação requer que o ambiente apresente condições de execução em certos momentos da execução, abordarei em detalhes no step-by-step desta parte. Antes de entrar nos detalhes do step-by-step do upgrade do "patch set release", seguiremos a seguinte ordem, primeiramente GI e posteriormente RDBMS.

GRID_HOME - GI - Grid Infrastructure

Caso você se depare com este erro, “INS-40406 – The installer detects no existing Oracle Grid Infrastructure software”, conforme descrito abaixo:

 

Buscando nas documentações oficiais encontrei a seguinte descrição para este erro.

Obviamente, não faz o mínimo sentido, uma vez que existe um GRID_HOME instalado cujo release é 11.2.0.3.0 (Estamos fazendo upgrade para o 11.2.0.4.0), verificando os logs do runInstaller, foi possível perceber que o instalador verifica a existência de um GRID_HOME usando o oraInventory, mais precisamente o arquivo inventory.xml, que no meu cenário esta localizando em /u01/oraInventory/ContentsXML/inventory.xml. Este arquivo é uma espécie de inventário de instalação, nele está especificado o que esta instalado com suas repectivas localizações.

O instalador busca no “<INVENTORY>” o “<HOME NAME>” corresponde ao Grid Infraestruture pertencente contido na “<HOME_LIST>”. Como todos nos sabemos o Grid Infraestruture é a consolidação do Oracle Clusterware e o ASM, que nas versões pre-11gR2 (11.1 e anterior) eram dois componentes distintos, a identificação do Clusterware Home no oraInventory (inventory.xml) em versões pre-11gR2 (11.1 e anterior) é feito pela flag “CRS=”, é importante frizar que o Oracle Clusterware não deixou de existir, ou seja, o Oracle Clusterware é uma parte do todo denominado Grid Infraestruture, conclui-se então que a flag  “CRS=” não esta obsoleta e deveria existir no inventory.xml.

Analisando os logs do runInstaller, busca um “<HOME NAME>” com a flag “CRS=”, com o objetivo de localizar a existência de um GRID_HOME instalado no servidor de banco de dados oracle, a não localização deste “<HOME NAME>” com a flag “CRS=”, implica na tela de erro “[INS-40406] The installer detects no existing Oracle Grid Infrastructure software on the system.”.

Para solucionar este problema é necessário adicionar a flag “CRS=” com valor “true”, conforme mostrado abaixo:

<HOME NAME="Ora11g_gridinfrahome1" LOC="/u01/app/product/grid/11.2.0.3" TYPE="O" IDX="1" CRS="true"/>

Esta tela explica o exemplo acima citado, onde uma nova instalação do binário deve ser feita em uma localização de diretórios diferente dos binários já existente. GRID_HOME 11.2.0.3.0 : /u01/app/product/11.2.0.3 GRID_HOME 11.2.0.4.0 : /u01/app/product/11.2.0.4

Utilizando o usuário root, execute o rootupgrade.sh, onde deve ser feito com a instance do ASM em estado STARTED, em outras palavras o ASM deve estar UP, caso contrário o script rootupgrade.sh acusara um erro informando ao DBA a necessidade do ASM “startado”.

Esta ambiente trata-se de um Oracle Database Standalone em ASM (Single Instance em ASM), caso está em um ambiente em RAC, você deve executar esse passo em todos os nodes existente no cluster.

ORACLE_HOME - RDBMS - Database Home

Esta ambiente trata-se de um Oracle Database Standalone em ASM (Single Instance em ASM), caso está em um ambiente em RAC, você deve executar esse passo em todos os nodes existente no cluster.

É importante ressaltar que a operação de “upgrade database” mostradas nos prints acima é feito pelo utilitário DBUA oriundo da nova instalação ORACLE_HOME (11.2.0.4.0). Assim, caso você tenha mais de um database sobre o ORACLE_HOME (Database RDBMS Home) é necessário fazer o “upgrade database” via DBUA para cada database existente no ORACLE_HOME.

Este artigo continua na segunda parte: Aplicação de Patch Set Update (PSU) 11.2.0.4.3

Carlos H. Y. Furushima é um DBA Oracle Sênior com ampla experiência e conhecimento em diversas áreas do banco de dados relacional é um especialista em "Performance, diagnostic and tuning", High Availability e Backup & Recovery, nos últimos anos de sua carreira profissional, Furushima vem trabalhado simultaneamente como DBA Oracle e Unix SysAdmin, atualmente atende empresas nacionais de grande porte do ramo de varejo e construção civil.

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.