O que é e como configurar Keep, Recycle e Default Cache do SGA do Oracle?
Seu servidor Oracle opera com uma quantidade substancial de RAM, mas a performance da aplicação é inconsistentemente lenta. Você observa no AWR (Automatic Workload Repository) que a taxa de acertos do Buffer Cache (Buffer Cache Hit Ratio) está boa, acima de 98%, mas mesmo assim, a aplicação sofre com esperas de I/O (db file sequential read, db file scattered read). Este cenário é um quebra-cabeça clássico do Oracle: as métricas de alto nível parecem saudáveis, mas a experiência do usuário final é ruim. A causa raiz, muitas vezes, não é o tamanho total da sua memória, mas a contenção dentro dela.
A configuração de memória do seu Oracle não é um bloco monolítico. O principal componente, o Buffer Cache, opera por padrão com um algoritmo LRU (Least Recently Used), que pode ser brutalmente ineficiente para cargas de trabalho mistas. Uma única consulta de relatório que varre uma tabela gigante pode “poluir” a cache, expulsando dela dezenas de tabelas de lookup pequenas e vitais para a performance transacional. A solução para este problema é a segregação inteligente de memória usando os pools KEEP, RECYCLE e DEFAULT. Entender como configurá-los é a diferença entre uma gestão de memória reativa e uma arquitetura de performance proativa.
Os Três Pools de Buffer: Uma Estratégia de Segregação
Dentro da grande área de memória do System Global Area (SGA), o DB_CACHE_SIZE define o tamanho do Buffer Cache. Por padrão, este é o pool DEFAULT. No entanto, você pode subdividir essa memória para criar pools especializados.
1. O Pool DEFAULT: O “Público Geral”
Este é o comportamento padrão. Todos os objetos (tabelas, índices) que não são explicitamente atribuídos a outro pool vivem aqui. Ele usa um algoritmo LRU para gerenciar quais blocos de dados permanecem na memória.
- Problema: Uma tabela grande lida por uma operação analítica pode ser considerada “recentemente usada” e, por isso, pode forçar a remoção de centenas de blocos de tabelas menores, mas que são acessadas com muito mais frequência por múltiplas transações.
2. O Pool KEEP: A “Área VIP”
O DB_KEEP_CACHE_SIZE define uma porção da memória reservada para objetos que você nunca quer que sejam removidos da cache.
- Propósito: Ideal para tabelas de lookup pequenas e médias que são acessadas constantemente pela aplicação. Pense em tabelas de CIDADES, STATUS_PEDIDO, CATEGORIAS_PRODUTO ou até mesmo sequências.
- Benefício: Manter esses objetos no pool KEEP garante que o acesso a eles seja sempre feito da RAM, eliminando o I/O de disco para os dados mais críticos e frequentes, e os protege da “poluição” causada por scans em tabelas grandes.
3. O Pool RECYCLE: A “Fila Expressa de Saída”
O DB_RECYCLE_CACHE_SIZE define uma área para objetos que você quer que sejam removidos da memória o mais rápido possível após o uso.
- Propósito: Perfeito para tabelas grandes que são acessadas de forma esporádica e, muitas vezes, aleatória. O objetivo aqui é o oposto do KEEP: você não quer que os blocos dessas tabelas permaneçam na memória, consumindo um espaço valioso que poderia ser usado por objetos mais importantes.
- Benefício: Isola o impacto de scans em tabelas massivas, impedindo que eles “lavem” o conteúdo útil do pool DEFAULT.
Guia Prático: Da Análise à Implementação
A configuração é um processo de três etapas: diagnosticar, alocar a memória e atribuir os objetos.
Etapa 1: Diagnóstico – Identificando os Candidatos
Como saber quais objetos pertencem a cada pool? Você precisa analisar os padrões de acesso.
Código: Encontrando Candidatos para o Pool KEEP
A seguinte consulta identifica objetos pequenos que são acessados com muita frequência (muitos “toques” nos seus blocos na buffer cache).
-- Identifica objetos pequenos (< 50MB) com alta frequência de acesso
-- (muitos blocos na buffer cache sendo "tocados")
SELECT
o.owner,
o.object_name,
o.object_type,
COUNT(bh.objd) AS buffer_touches,
ROUND(SUM(s.bytes) / 1024 / 1024, 2) AS size_mb
FROM
v$bh bh
JOIN
dba_objects o ON bh.objd = o.data_object_id
JOIN
dba_segments s ON o.owner = s.owner AND o.object_name = s.segment_name
WHERE
o.owner NOT IN ('SYS', 'SYSTEM')
AND s.bytes < (50 * 1024 * 1024) -- Limite de tamanho, ex: 50MB
GROUP BY
o.owner, o.object_name, o.object_type
HAVING
COUNT(bh.objd) > 1000 -- Limite de "toques", ajuste conforme sua carga
ORDER BY
buffer_touches DESC;
Os objetos no topo desta lista são fortes candidatos para o pool KEEP. Para o pool RECYCLE, procure o oposto: objetos muito grandes com um número relativamente baixo de “toques”.
Etapa 2: Configuração – Alocando a Memória
Você aloca a memória para os pools KEEP e RECYCLE com comandos ALTER SYSTEM. Importante: Esta memória é subtraída do pool DEFAULT (DB_CACHE_SIZE).
-- Exemplo: Alocar 1GB para o pool KEEP e 2GB para o pool RECYCLE
ALTER SYSTEM SET DB_KEEP_CACHE_SIZE = 1G SCOPE = BOTH;
ALTER SYSTEM SET DB_RECYCLE_CACHE_SIZE = 2G SCOPE = BOTH;
Etapa 3: Atribuição – Movendo os Objetos
Finalmente, você atribui cada objeto ao seu respectivo pool.
-- Atribui uma tabela de lookup ao pool KEEP
ALTER TABLE scott.categorias STORAGE (BUFFER_POOL KEEP);
-- Atribui uma tabela de log gigante ao pool RECYCLE
ALTER TABLE app.logs_auditoria STORAGE (BUFFER_POOL RECYCLE);
-- Para retornar um objeto ao pool padrão
ALTER TABLE scott.categorias STORAGE (BUFFER_POOL DEFAULT);
Da Configuração Manual à Otimização Contínua com dbsnOOp
A análise manual é poderosa, mas é uma fotografia do momento. A carga de trabalho da sua aplicação evolui, e um objeto que hoje é “quente” pode se tornar “frio” no próximo mês. Manter essa segregação otimizada é um desafio contínuo.
A dbsnOOp automatiza este processo de análise.
- Análise Contínua de Acesso: Em vez de executar queries pontuais, a dbsnOOp monitora continuamente os padrões de acesso a cada segmento do seu banco de dados.
- Recomendações Proativas: Com base nessa análise histórica, a plataforma pode identificar e recomendar proativamente quais objetos são os melhores candidatos para os pools KEEP e RECYCLE, transformando o tuning de memória de uma tarefa reativa em uma ciência de dados contínua.
Pare de usar uma estratégia de “tamanho único” para o recurso mais crítico do seu banco de dados.
Implemente a segregação de memória e garanta que suas consultas mais importantes sempre encontrem seus dados na via expressa da RAM. Marque uma reunião com nosso especialista ou assista a uma demonstração na prática.
Saiba mais sobre o dbsnOOp!
Visite nosso canal no youtube e aprenda sobre a plataforma e veja tutoriais
Aprenda sobre monitoramento de banco de dados com ferramentas avançadas aqui.
Leitura Recomendada
- IA Tuning Banco de Dados: O processo de identificar e segregar objetos para diferentes pools de cache é uma tarefa de otimização complexa. Entenda como a Inteligência Artificial pode automatizar essa análise e fornecer recomendações contínuas.
- dbsnOOp: a Plataforma de Monitoramento e Observabilidade com DBA Autônomo: Descubra a visão completa da plataforma e como o monitoramento granular da memória e do acesso a objetos se encaixa em uma estratégia maior de gestão de dados autônoma e preditiva.
- Histórico de Queries: Como Usamos Telemetria Para Encontrar a Causa de um Bug Intermitente: O bug mais traiçoeiro é aquele que não se repete. Ele aparece de forma intermitente, em momentos aleatórios, com impacto imprevisível.