Pular para o conteúdo principal

Erro durante movimentação/recriação GI Management Repository(GIMR / MGMTDB)


O Grid Infrastructure Management Repository (GIMR ) é um banco de dados multitenant com um PDB que coleta em tempo real métricas sobre a operação do CHM( RAC cluster health monitor).


O GIMR foi introduzido no Oracle 12.1.0.1 e na 12.1.0.2 virou obrigatório. Na versão 19c, voltou a ser opicional. O GIMR roda somente em um dos nós do cluster e pode estar em um diskgroup com redundância externa.

A Oracle recomenda um diskgroup separado para o GIMR e no ambiente em que peguei, ele estava junto com o OCR. Então resolvi separar.
É disponibilizado pela Oracle um utilitário chamado mdbutil.pl para auxiliar na manipulação desse banco de dados. (Doc ID 2065175.1)

Abaixo vou descrever o procedimento que realizei para corrigir o erro durante a migração utilizando esse utilitário da Oracle.


Verificando o status do GIMR

[grid@teste01 ~]$ /tmp/mdbutil.pl --status
mdbutil.pl version : 1.98
2019-09-25 16:04:05: I Checking CHM status...
2019-09-25 16:04:06: I Listener MGMTLSNR is configured and running on teste
2019-09-25 16:04:08: I Database MGMTDB is configured and running on teste
2019-09-25 16:04:08: I Cluster Health Monitor (CHM) is configured and running
--------------------------------------------------------------------------------
CHM Repository Path = +OCRVOTE/_MGMTDB/936558468F88273FE053B403010A88B0/DATAFILE/sysmgmtdata.277.1019919313
MGMTDB space used on DG +OCRVOTE = 23640 Mb
--------------------------------------------------------------------------------
 

GIMR está em execução no diskgroup +OCRVOTE. Então criei o diskgroup +GIMR e abaixo tento realizar a migração para o diskgroup criado.




[grid@teste01 ~]$ /tmp/mdbutil.pl --mvmgmtdb --target=+GIMR -debug
mdbutil.pl version : 1.98
2019-09-20 14:05:43: D Executing: /u01/app/18.3.0/grid/bin/srvctl status diskgroup -g GIMR
2019-09-20 14:05:44: D Exit code: 0
2019-09-20 14:05:44: D Output of last command execution:
O Grupo de Discos GIMR está em execução em teste01,teste02
2019-09-20 14:05:44: E Specified Target +GIMR Not accessible on teste01!
 


Após olhar logs do banco, grid e não achar nada de anormal, resolvi verificar o código fonte do mdbutil.pl.
Vi que no tratamento do erro ele procurava por: '...is running..." e saída do comando no terminal era "...está em execução". Ou seja, meu problema era o idioma.

 "O Grupo de Discos GIMR está em execução em teste01,teste02".

Após entender a causa raiz do erro, realizei a alteração do idioma e executei novamente o comando para migração. Dessa vez funcionou.

[grid@teste01 oraInventory]$ export LC_ALL=en_US.utf-8



[grid@teste01 ~]$ /tmp/mdbutil.pl --mvmgmtdb --target=+GIMR
mdbutil.pl version : 1.98
Moving MGMTDB, it will be stopped, are you sure (Y/N)? y
2019-09-25 16:04:56: I Checking for the required paths under +GIMR
2019-09-25 16:04:57: I Creating new path +GIMR/_MGMTDB/PARAMETERFILE
2019-09-25 16:04:59: I Creating new path +GIMR/_MGMTDB/CONTROLFILE
2019-09-25 16:05:01: I Creating new path +GIMR/_MGMTDB/ONLINELOG
2019-09-25 16:05:03: I Creating new path +GIMR/_MGMTDB/DATAFILE
2019-09-25 16:05:05: I Creating new path +GIMR/_MGMTDB/TEMPFILE
2019-09-25 16:05:06: I Creating new path +GIMR/_MGMTDB/DATAFILE/PDB$SEED
2019-09-25 16:05:08: I Creating new path +GIMR/_MGMTDB/DATAFILE/TEMPFILE/PDB$SEED
2019-09-25 16:05:09: I Creating new path +GIMR/_MGMTDB/DATAFILE/tjrah_cluster
2019-09-25 16:05:11: I Creating new path +GIMR/_MGMTDB/TEMPFILE/tjrah_cluster
2019-09-25 16:05:11: I Getting MGMTDB Database files location
2019-09-25 16:05:11: I Getting MGMTDB Temp files location
2019-09-25 16:05:11: I Getting MGMTDB PDB PDB$SEED files location
2019-09-25 16:05:11: I Getting MGMTDB PDB PDB$SEED Temp files location
2019-09-25 16:05:12: I Getting MGMTDB PDB GIMR_DSCREP_10 files location
2019-09-25 16:05:12: I Getting MGMTDB PDB GIMR_DSCREP_10 Temp files location
2019-09-25 16:05:16: I Creating temporary PFILE
2019-09-25 16:05:16: I Creating target SPFILE
2019-09-25 16:05:18: I Stopping the Cluster Health Analysis Resource
2019-09-25 16:05:26: I Stopping mgmtdb
2019-09-25 16:05:51: I Copying MGMTDB DBFiles to +GIMR
2019-09-25 16:05:55: I Copying MGMTDB PDB$SEED DBFiles to +GIMR
2019-09-25 16:06:00: I Copying MGMTDB PDB DBFiles to +GIMR
2019-09-25 16:06:48: I Creating the CTRL File
2019-09-25 16:07:10: I The CTRL File has been created and MGMTDB is now running from +GIMR
2019-09-25 16:07:10: I Setting MGMTDB SPFile location
2019-09-25 16:07:11: I Modifing the init parameter
2019-09-25 16:07:11: I Removing old MGMTDB
2019-09-25 16:07:12: I Changing START_DEPENDENCIES
2019-09-25 16:07:12: I Changing STOP_DEPENDENCIES
2019-09-25 16:07:12: I Restarting MGMTDB using target SPFile
2019-09-25 16:08:27: I Starting the Cluster Health Analysis Resource
2019-09-25 16:08:29: I MGMTDB Successfully moved to +GIMR!
 

Comentários

Tive o mesmo problema e configurando a linguagem conforme explicado acima resolveu. MUITO OBRIGADO!

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