DB Smart Flash Cache

I – Introdução

Saudações pessoal, esse artigo é um pouco diferente dos outros, ele aborda a feature DB Smart Flash Cache sob uma perspectiva teórica em relação a prática. Esse recurso está disponível a partir da versão Oracle 11gR2. Nós sabemos que I/O, consome tempo, ciclos de CPU e memória. Sabemos também que o I/O na memória é mais rápido, porem mais caro para as empresas. E se tivermos um meio termo ? melhor, mudo a pergunta, e se tivermos um db_cache_size  estendido ? O DB Smart Flash Cache amplia a discussão referente a flexibilidade de um recurso tão discutido, a memória.

II – O que é ?

Conceitualmente, o DB Smart Flash Cache é a extensão do buffer cache, residindo em um flash disk. Inclusive, com a mesma hierarquia do cache utilizado pelas CPUs atuais, onde, o dado com a maior frequência de acesso, será mantido no nível 1 do cache, entenda-se na memória. O dado com menor frequência de acesso será mantido no nível 2 do cache, entenda-se flash disk.

Podemos concluir que, poderemos ter um buffer cache maior que a memória do servidor. Um flash disk , juntamente com seus devices, possue maior capacidade de armazenamento comparado a DRAM (tipo de memória RAM), e melhor throughput e menor latência comparado aos discos comuns, mesmo os fiber channel.

Essas vantagens resultam em uma grande melhoria de performance com custo moderado. O melhor tipo de flash disk, para ser utilizado em banco de dados, são aqueles que oferecem maior IOPs em escrita, em relação a  IOPs em leitura.

OBS: IOPs é a capacidade de processamento de I/O por segundo.

III – Utilização e custo

O DB Smart Flash Cache fornece melhor performance. Em um sistema de banco de dados, quando o uso de memória chega perto do máximo, o gargalo de I/O em disco é inevitável, nessa situação, a única opção é comprar mais memória. Mas, o preço por GB/$ não é barato e outro agravante, pode ser a limitação de slots do servidor para estender a memória. Então, a empresa é forçada a adquirir novos servidores.

Flash disks são perfeitos nessa situação. Pelo mesmo preço a ser gasto em memória DRAM, é possível adquirir 5 ou 10 vezes mais em memória flash. Configurando memória flash, juntamente com a memória do servidor, é possível maximizar a quantidade de memória para o buffer cache do banco.Sob a perspectiva da administração e manutenção, basta a configuração de apenas dois parâmetros.

Essa feature fornece, uma interface para ajustar o controle de granularidade em nível de objeto, através do mecanismo LRU no flash cache.

É possível também , controlar o mecanismo da LRU, especificando clausulas no nível de objeto.

 

IV – Arquitetura

Quando um processo tenta acessar um bloco e, esse bloco não está na memória, (buffer cache), uma leitura no disco será realizada, em seguida o bloco será carregado no buffer cache (physical read). Depois que esse bloco é acessado, provavelmente ele será retirado da memória para dar lugar a outros blocos que necessitam ser acessados por outros processos. Quem controla a retirada do bloco na memória é o algoritmo LRU (list recently used).

Com o DB Flash Cache, quando um bloco sai da memória (buffer cache) para dar lugar a outro bloco, seu conteúdo é escrito no flash cache pelo processo background Database Writer (DBWR), e o cabeçalho do bloco em questão, será mantido como metadado no flash DEFAULT ou na KEEP LRU list. Isso dependerá do valor definido no atributo FLASH_CACHE.

Se o valor do atributo FLASH_CACHE for KEEP, os blocos que estiverem na KEEP LRU, serão mantidos para que outros blocos não os sobrescrevam. Se o valor do atributo FLASH_CACHE for DEFAULT, então, os blocos que estiverem na KEEP LRU poderão ser sobrescritos para dar lugar a outros blocos.

Quando um bloco estiver fora do buffer_cache e ele for requisitado para leitura, o Oracle tentará ler o bloco da memória flash, caso contrário o bloco será lido do disco (physical read).

A consistência de um bloco na memória flash em ambientes Oracle RAC, é garantida da mesma forma que a consistência que qualquer outro bloco no do Cache Fusion.

Um dirty block nunca é colocado na memória flash. Dirty blocks são tratados dessa maneira por que o checkpoint no bloco continuará sendo no buffer cache.

Para efeito de comparação, é claro que tudo dependerá do hardware e configuração de melhores práticas, o tempo de leitura de um bloco em disco demora em média 10ms, enquanto que a leitura de um bloco no flash cache, leva em média de 1ms, ou seja, compensa.

 

V – Configurando o DB Smart Flash Cache

Dois parâmetros são utilizados na configuração do DB Smart Flash Cache

DB_FLASH_CACHE_FILE e DB_FLASH_CACHE_SIZE.

 

Parâmetro DB_FLASH_CACHE_FILE

DB_FLASH_CACHE_FILE= ‘/dev/flash1’

DB_FLASH_CACHE_FILE= ‘/u03/flash1.dbf ‘

DB_FLASH_CACHE_FILE= ‘+DGFLASHCACHE/flash_cache’

 

Esse parâmetro especifica o nome do arquivo presente no sistema operacional. Caso o arquivo não existir no momento do startup, o Oracle criá-la o arquivo.

Como podemos ver, o db_flash_cache_file pode ser apresentado para a instância, como uma raw device, um file system ou um diskgroup na ASM. O flash cache não é compartilhado entre instâncias do Oracle RAC, cada instância tem sua própria memória flash. Esse parâmetro precisa definido antes do startup da instância e não pode ser alterado depois que instância foi startada.

 

Parâmetro DB_FLASH_CACHE_SIZE

Esse parâmetro especifica o tamanho da memória flash. Ele precisa ser definido antes do startup da instância e pode ser alterado apenas para 0 (isso desabilita a utilização da memória flash).  Quando o flash cache é desabilitado, ele poderá somente ser habilitado com o restartup da instância. O resizing dinâmico desse parâmetro não é suportado, ou seja, ele não é gerenciado pelo automatic shared memory management (memory_target <> 0).

Os demais blocos pertencentes a outros pools de memória como large_pool, java_pool, shared_pool, streams_pool não são suportados na memória flash.

 

VI – Melhores práticas

 

Por regra geral, o tamanho a ser configurado para a memória flash, deverá ser entre duas a dez vezes o tamanho do buffer cache, qualquer configuração abaixo disso não haverá ganho de performance.

Se o banco estiver configurado com automatic shared memory management, considerar no mínimo 80% do tamanho da SGA_TARGET para a definição do tamanho da memória flash.

Para cada bloco que é movido do buffer cache para a memória flash, a quantidade de bytes para manutenção do metadado do bloco, será de 100 bytes para single instance e, aproximadamente 200 bytes para o Oracle RAC. Essa informação é mantida no buffer_cache logo, é necessário considerar esse overhead da seguinte maneira.

Se estiver utilizando gerenciamento de memória manual: O tamanho do db_cache_size deverá ser aumentado respeitando o seguinte algoritmo:

 

Single instance:

DB_CACHE_SIZE=DB_CACHE_SIZE+Qtde de blocos da memória flash X 100 bytes

Oracle RAC:

DB_CACHE_SIZE=DB_CACHE_SIZE +Qtde de blocos da memória flash X 200 bytes

 

Exemplo de calculo para single instance:

DB_CACHE_SIZE= 2G ou 2147483648 bytes

Tamanho da memória flash= 10 Gb ou 10737418240 bytes

Tamanho do bloco= 8K ou 8192 bytes

Overhead do bloco = 100 bytes

DB_CACHE_SIZE= 2147483648+((10737418240/8192)*100)

DB_CACHE_SIZE= 2147483648+(1310720*100)

DB_CACHE_SIZE= 2147483648+131072000

O tamanho do DB_CACHE_SIZE deverá ser acrescido em 125mb, ou seja, seu valor deverá ser 2.125 mb.

Se o ambiente for RAC, alterar o valor do overhead do bloco para 200 bytes.

Se estiver utilizando automatic shared memory management, considerar o mesmo algoritmo acima, porem o parâmetro a ser aumentado não será o DB_CACHE_SIZE e sim  SGA_TARGET.

 

VII – Especificação do DB Smart Flash Cache no nível de objeto

É possível especificar o DB Smart Flash Cache em uma tabela utilizando a opção FLASH_CACHE na clausula storage.

 

Exemplo:

CREATE TABLE TB_CLIENTES …… STORAGE (FLASH_CACHE KEEP|NONE|DEFAULT);

Onde:

DEFAULT – Quando um bloco se “tornar velho” no buffer cache, o bloco será escrito na memória flash. Os blocos que estão na memória flash são mantidos algoritmo pelo flash LRU list, logo, esses blocos podem ficar velhos na memória flash e serão retirados da memória flash para acomodar outros blocos.

KEEP = Possui as mesmas características da opção DEFAULT, porem esses blocos serão mantidos separados dos blocos com  a opção DEFAULT na memória flash. O Oracle tentará manter sempre os blocos com a opção KEEP na memória flash.

NONE = Blocos com essa opção nunca serão colocados na memória flash.

Por questões de consistência, o Oracle considera leituras físicas para as leituras realizadas na memória flash . Os relatórios AWR possuem estatísticas específicas para a memória flash.

 

VIII – Conclusão

Vejo essa feature sob duas ópticas: tecnicamente,  a possibilidade de estender o cache do banco independentemente a quantidade de slots de memória suportada pelo servidor, e financeiramente pois discos SDD são mais baratos que memória DRAM.  Sempre lembrando da velha máxima, para qualquer ambiente de produção, desenvolver, testar, homologar e implementar.

 

Forte abraço e até a próxima

 

IX – Referências bibligráficas

ORACLE University. Oracle Database 11g New Features for Administrators: 16-Performance Enhacements . California USA. 2.1 ed. Setembro 2010. v.II, p.105-111

Disponível em : http://www.oracle.com/technetwork/middleware/bi-foundation/exadata-smart-flash-cache-twp-v5-1-128560.pdf. Acessado em 04/11/2011

Anúncios
Comente ou deixe um trackback: URL do Trackback.

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair /  Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair /  Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair /  Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair /  Alterar )

Conectando a %s

%d blogueiros gostam disto: