Pular para o conteúdo principal

Usando Oracle Database Smart Flash Cache



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 "_serial_direct_read"=NEVER;
 

O valor a ser utlizado no parâmetro db_flash_cache_size  é feito da seguinte maneira. Pegue 80% do valor da SGA da sua base e multiplique por 2 a 10 vezes.

db_flash_cache_size   = (SGA*80%)*10



Verificando o uso do Smart Flash Cache

Antes de realizar a consulta na tabela teste, podemos verificar na visão v$bh  que não temos o status flashcur - current flash cache buffer. Mais detalhes da visão aqui.

select status, count(*) from v$bh group by status;


STATUS         COUNT(*)
----------         ----------
cr                       109
xcur                 253854
 

Fiz a primeira consulta na tabela TESTE e ele demorou 2min e 41 segundos.

SQL> select count(*) from c##teste.teste;

  COUNT(*)
----------
  15000000

Decorrido: 00:02:41.87
 
Após isso, fiz a consulta na visão v$bh e veja que dessa vez temos o status flashcur.

select status, count(*) from v$bh group by status;


STATUS         COUNT(*)
----------         ----------
cr                      138
flashcur            3498035
xcur                  253825


Fiz a consulta novamente na tabela TESTE e como temos os blocos em cache, o tempo caiu para 47 segundos..

SQL>  select count(*) from c##teste.teste;

  COUNT(*)
----------
  15000000

Decorrido: 00:00:47.67



Simulando queda do diskgroup

Como já vimos, temos blocos em cache usando o smart flash cache, a ideia é simular uma perca nos discos que compões esta área.

 Fiz login na instância ASM e desmontei o grupo de discos forçando.

SQL> alter diskgroup nvme dismount force;

Diskgroup altered.



No log da instância ASM consta que o flash cache foi desabilitado.

2019-04-09 13:34:54.644000 -03:00
Flash cache file +NVME/flash.dat header read failed with error 0
Errors in file /u01/app/oracle/diag/rdbms/sproch/SPROCH/trace/SPROCH_gen0_327938.trc:
Flash Cache: disabling started for file
0
Flash cache: future write-issues disabled
Start disabling flash cache writes..
Flash cache: DBW0 stopping flash writes...
Flash cache: DBW4 stopping flash writes...
Flash cache: DBW5 stopping flash writes...
Flash cache: DBW8 stopping flash writes...
Flash cache: DBW3 stopping flash writes...
Flash cache: DBW7 stopping flash writes...
Flash cache: DBW1 stopping flash writes...
Flash cache: DBW6 stopping flash writes...
Flash cache: DBW2 stopping flash writes...


 Consultando a base de dados, podemos ver que nossa instância permaneceu ativa. Ou seja, podemos usar o recurso sem a preocupação de falha no diskgroup.

SQL> select open_mode from v$database;

OPEN_MODE
--------------------
READ WRITE

Comentários

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