Iago DBA

Em casos de full scans repetidos nas mesmas tabelas, muito direct path read ou execuções batch com múltiplas etapas. O Banco de dados pode se beneficiar muito com a configuração do Big Table Caching, nesse artigo será apresentado um pouco desse recurso.

Introdução

Antes de tudo, é importante revisarmos qual a função do Buffer Cache dentro do Oracle.

O buffer cache é um conjunto de buffers de memória dentro da SGA. Nele, cada buffer armazena um bloco do banco de dados (O tamanho do bloco é definido pelo parâmetro DB_BLOCK_SIZE na criação do banco);

Principais características do Buffer Cache:

> O LRU é um algoritmo usado pelo buffer cache para decidir quais blocos devem ser removidos da memória quando é preciso liberar espaço. Esse algoritmo é baseado no tempo desde o último acesso ao bloco.

> Blocos menos recentemente usados saem primeiro;

> Blocos mais acessados recentemente permanecem no cache;

> O controle de concorrência multiversão (MVCC) permite que leitores e escritores acessem versões diferentes do mesmo bloco simultaneamente;

> Cache Fusion permite que o banco funcione de forma transparente em um cluster (RAC), mantendo coerência entre caches;

> Checkpoint incremental mantém uma taxa de I/O estável, garantindo tempo de recuperação previsível;

> Operações de direct-path I/O usam buffers privados e prefetch assíncrono, ideais para cargas analíticas (DSS);

Tudo bem, mas agora onde que entra o Big Table Caching nisso tudo?

O big table caching basicamente é uma área opcional do buffer cache, que nós podemos reservar um espaço nela para armazenar dados de table scans paralelos (isso já vai ajudar muito a reduzir I/O para tabelas grandes).

Configuração

Os principais parâmetros para nós seriam o PARALLEL_DEGREE_POLICY = AUTO/ADAPTIVE e DB_BIG_TABLE_CACHE_PERCENT_TARGET.

PARALLEL_DEGREE_POLICY: Esse parâmetro do Oracle Database controla como o banco decide usar paralelismo e como define o grau de paralelismo para as consultas.
Quando está como AUTO, o banco decide automaticamente se a query deve rodar em paralelo ou não.
Quando está como ADAPTIVE, o banco se adapta durante a execução, baseado no comportamento real da query.

DB_BIG_TABLE_CACHE_PERCENT_TARGET: Esse segundo parâmetro é o que realmente define quanto do buffer cache será reservado para big tables.

SQL> ALTER SYSTEM SET db_big_table_cache_percent_target = 40;
System altered.
SQL> show parameter db_big_table_cache_percent_target
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
db_big_table_cache_percent_target    string      40
SQL>

Nesse exemplo acima, eu setei o parâmetro “db_big_table_cache_percent_target” para 40. Como o meu db_cache_size está setado para 100G, a minha buffer cache seria distribuída da seguinte forma:

Large table scans utilizam: 40 GB e OLTP utiliza: 60 GB

Funcionamento do Big Table Caching

Se o big table cache não comportar todas as tabelas:

> As demais são lidas diretamente do disco (direct read) automaticamente;

> Apenas as mais acessadas são mantidas em cache através de um algoritmo de temperatura do objeto (object-level), diferente do Buffer Cache que por default utiliza o LRU

O big Table Caching também é excelente para evitar Thrashing (ficar carregando e removendo dados o tempo todo), pois no caso de uma tabela inteira não caber no cache, ainda seria possível armazenar apenas parte dessa tabela.

Exemplo:

• 95% da tabela fica em cache
• 5% continua sendo lido do disco

Isso evita que o Thrashing ocorra com muita frequência.

Definição de temperatura

Quanto mais acessado o objeto, maior a sua temperatura.

Quando o cache enche, um objeto só é removido se entrar outro mais “quente” (mais acessado). Isso evita que sejam removidos dados importantes do cache.

Conclusão

O recurso do big table cache permite que seja alocada uma parte do Buffer Cache para um cache de tabela grande para full table scans, o que pode reduzir significativamente o acesso ao disco e melhorar o desempenho. Essa recurso pode ajudar muito em casos de direct path read, db file scattered read ou db file sequential read por exemplo.