Oracle RAC - Install & Patch at the same time - From 19.3.0.0 to 19.17.0.0

Hello all

Yesterday, I was installing a new Oracle RAC 19c and I had an unusual error in the Oracle Base directory.

I was installing the base version of Grid, 19.3.0.0.

The error was this: 

INS-4400 - The Oracle Home location contains directories or files on following remote nodes.

I asked in the GUOB user group and after many checks, the solution was to apply the RU before installation. My friends Vini, Mufalani & Rodrigo Jorge helped me to check these points. Thanks.

This is the Step-by-Step:

1) Create a new GRID HOME

cd /u01/app

mkdir -p 19.17.0.0/grid

export GRID_HOME=/u01/app/19.17.0.0/grid

2) Update Opatch

Check & download Opatch last version (6880880)

cd $GRID_HOME

unzip /u01/INSTALL/opatch/p6880880_190000_LINUX.zip -o /u01/app/19.17.0.0/grid

3) Important (tip from Rodrigo Jorge 😎):

    Source: Applying Patches During an Oracle Database Installation or Upgrade

4) Applying the patch "GI RELEASE UPDATE 19.17.0.0.0 (System Patch)"

cd $GRID_HOME

unzip p34416665_190000_Linux-x86-64.zip

./gridSetup.sh -applyRU 34416665

Preparing the home to patch...

Applying the patch 34416665...

Successfully applied the patch.

The log can be found at: /tmp/GridSetupActions2022-10-31_04-51-49PM/installerPatchActions_2022-10-31_04-51-49PM.log

Source: Real Application Clusters Installation Guide for Linux and UNIX

After that, it was easy to continue the installation.

I hope that help you.

Regards

Mario

Erro ao executar um duplicate database em grid 12c (12.1.0.2.0)

Fala pessoal.

Hoje, montando um ambiente de testes aqui para um artigo de GoldenGate me deparei com um erro chatinho quando fui executar um duplicate from active database.

Estava com todas as configurações corretas, usando o script abaixo:

RUN 

{

set until scn 2462883;

set newname for datafile 1 to new;

set newname for datafile 2 to new;

set newname for datafile 3 to new;

set newname for datafile 4 to new;

set newname for datafile 5 to new;

set newname for datafile 6 to new;

set newname for tempfile 1 to new;

DUPLICATE TARGET DATABASE TO "ggcopy" FROM ACTIVE DATABASE;

}

Nada demais, clonando uma base de testes.

Estava tomando o erro:

sql statement: alter system set  db_unique_name =  ''GGCOPY'' comment= ''Modified by RMAN duplicate'' scope=spfile

RMAN-00571: ===========================================================

RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============

RMAN-00571: ===========================================================

RMAN-03002: failure of Duplicate Db command at 10/29/2016 09:12:29

RMAN-05501: aborting duplication of target database

RMAN-03015: error occurred in stored script Memory Script

RMAN-03009: failure of sql command on clone_default channel at 10/29/2016 09:12:29

RMAN-11003: failure during parse/execution of SQL statement: alter system set  db_unique_name =  'GGCOPY' comment= 'Modified by RMAN duplicate' scope=spfile

ORA-32017: failure in updating SPFILE

ORA-65500: could not modify DB_UNIQUE_NAME, resource exists

Pesquisando um pouco no MOS, como diz minha linda esposa, PAH!!! estava lá, um bug.

Note: ORA-65500 When Trying To Duplicate a Database (Doc ID 1963620.1)

Neste note, é referenciao um bug: Bug 20977794 - RMAN-3002 ORA-65500 from RMAN duplicate on RAC (Doc ID 20977794.8)

Existe um patch disponível, mas como não é o meu foco acertar essa base, eu nem apliquei.

Então, confirmando o bug, a minha base de testes estava registrada no meu grid, e por isso era dada a mensagem que o resource já existia.

Para resolver foi simples, aplicando o workaround do note, ou seja, excluir a base a ser clonada do grid e adicionar após o processo.

[ggcopy.rac12c1 dbs]$ srvctl remove database -d ggcopy

Remove the database ggcopy? (y/[n]) y

É isso, abraço.

Mario

BUG: Oracle Cluster Health Monitor (CHM) using large amount of space

Fala pessoal...

Esses dias peguei um bug que nunca havia visto, por isso vou registrar aqui para todos.

Depois de um simples df -h, o resultado que recebo em um dos nodes do RAC 11g de um cliente é que meu "/oracle" (onde instalo os binários do GRID e RDBMS), estava com mais de 90% de ocupação.

Achei estranho e ao verificar minhas pastas, cheguei ao arquivo "crfclust.bdb" com quase 30G de tamanho.

-rw-r----- 1 root root 30G Oct  5 18:19 crfclust.bdb

Ao acessar o MOS, encontrei o note "Oracle Cluster Health Monitor (CHM) using large amount of space (more than default) (Doc ID 1343105.1)". Esse note está relacionado ao bug "BUG:10165314 - CHM/CRF/IPDOS REPOSITORY EXCEEDS 1GB AFTER ADD/REMOVE NODE OR FRESH INSTALL".

Só como curiosidade e bem rapidamente, o CHM coleta estatísticas (métricas de sistema) em real-time do SO. A coleta abrange memória, uso de SWAP, processos, I/O, etc. Essa coleta se dá através do "Cluster Health Monitor Service" - ora.crf. 

No note "Cluster Health Monitor (CHM) FAQ (Doc ID 1328466.1)", você encontra diversas informações muito mais detalhadas sobre esse serviço.

Voltando ao nosso problema, não podemos ficar com esse arquivo tão grande assim. O procedimento é simples para recriar o mesmo.

Esse procedimento pode ser feito com o cluster no ar, tranquilamente. E deve ser feito como ROOT.

1) Exporte as variáveis de ambiente:

        su -

export ORACLE_GRID=/oracle/app/11.2.0/grid

2) Execute o comando abaixo para confirmar o local do nosso arquivo
$ORACLE_GRID/bin/oclumon manage -get reppath

A saída esperada é essa:
CHM Repository Path = /oracle/app/11.2.0/grid/crf/db/srv1

Done

3) Vá até o diretório e identifique o arquivo
cd /oracle/app/11.2.0/grid/crf/db/srv1

ls -lrht crfclust.bdb
-rw-r----- 1 root root 30G Oct  5 18:19 crfclust.bdb

4) Vamos parar o serviço do CHM
$ORACLE_GRID/bin/crsctl stop res ora.crf -init
CRS-2673: Attempting to stop 'ora.crf' on 'srv1'

5) Remover o arquivo
rm -f crfclust.bdb

6) Iniciamos o serviço novamente
$ORACLE_GRID/bin/crsctl start res ora.crf -init
CRS-2672: Attempting to start 'ora.crf' on 'srv1'
CRS-2676: Start of 'ora.crf' on 'srv1' succeeded

Nesse momento, o arquivo "crfclust.bdb" será gerado novamente e a coleta será retomada. Além da perda das estatísticas, a exclusão desse arquivo não gera mais nenhum problema para o cluster.

That's it folks.

Espero que seja útil a vocês.

Abraço
Mario