Então...

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 con

Introduzido na versão 11R2 do banco de dados Oracle, o Database Smart Flash Cache é uma feature que ajuda a ter ganhos de desempenho em sistema com carga intensa de IO. Ele funciona como se fosse uma segunda camada de cache para o banco. Aqui você pode entender melhor como funciona a tecnologia. A idea aqui é realizar alguns testes de uso e mostrar que o banco de dados pode funcionar sem problemas caso de indisponibilidade do hardware que irá implementar essa camada. O Ambiente - Oracle Database 18c - Red Hat Enterprise Linux Server release 7.6 (Maipo) - Diskgroup NVME. Usei placas NVME da Dell. Parâmetros alterados - Criei um tabela TESTE com 27Gb - Para evitar direct path reads quando fizer um select em tabelas grandes:  _serial_direct_read=NEVER alter system set db_flash_cache_file='+NVME/flash_cache' sid='*' scope=spfile; alter system set db_flash_cache_size='60g' scope=spfile sid='*' scope=spfile; alter system set "_seri

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

Perocona XtraBackup  é uma ferramenta open source que faz um hot backup físico da sua base MySQL sem parada do seu banco. Então se você tem o MySQL na versão free, o XtraBackup pode te ajudar muito.  Com ele é possível realizar backups full, incremental, compactar e até criptografar os backups da sua base. A ideia desse post é mostrar como é simples fazer backups usando a ferramenta XtraBackup. Maiores detalhes/instalação   aqui Criando um backup full Para iniciar o full, basta especificar o diretório que será guardado --target=dir. Se o diretório não existir, o xtrabackup irá criar, porém não irá sobrescrever se já existir arquivos na pasta. xtrabackup --user=root --password=zabbix --backup --target-dir=/bkp/percona/ No final do backup você verá os valores (início e fim) dos LSN dos logs da sua base. xtrabackup:  Redo log (from LSN 11930540802 to 11930753909) was copied Preparando / Restaurando o backup Antes de realizar o restore, existe a fase de pre