Publicidade

COMPUTERWORLD - O portal voz do mercado de TI e Comunicação

Tecnologia

Teste do banco de dados Oracle 11g : Result Cache

Confira a terceira parte do teste completo sobre várias das novas funcionalidades do Oracle 11g. Vale apostar na atualização?

Por Infoworld, EUA

13 de junho de 2008 - 08h30
página 1 de 1

O Result Cache é um recurso que pode fazer você alcançar o sucesso ou fracasso total.

O Result Cache lhe permite confinar eficazmente o resultado de uma consulta em um buffer especial na memória, fazendo o bypass da pesquisa em disco para chamadas subseqüentes da mesma consulta. Você poder ter em cache consultas inteiras, subconsultas ou até funções PL/SQL.

Obviamente, a chamada da consulta tem que ser a mesma que versão em cache – e aí reside o problema. Com muita freqüência, as consultas diferem apenas nos parâmetros que são passados (o caso da maioria das consultas OLTP). Muitas consultas individuais em cache, mas pouquíssima reutilização.

Neste aspecto, o Oracle lhe dá três níveis diferentes nos quais você pode especificar seu cache de resultados: o nível de banco de dados, o nível de sessão e o nível de consulta.

Estas opções são muito poderosas, para o bem e para o mal, por isso sugiro o nível de consulta ou de sessão, a menos que você tenha testado a fundo o nível de banco de dados e saiba exatamente o que esperar.

Teste de Estresse - Oracle 11g
Teste do Oracle 11g – Primeira Parte
Teste do Oracle 11g – Tunning e Saúde
Teste do Oracle 11g – Snapshot Standby
Teste do Oracle 11g – Active Data Guard
Teste do Oracle 11g – Real Application Testing
Teste do Oracle 11g - Advanced Compression

No nível de banco de dados, todos os resultados das consultas vão estar em cache, incluindo os que não precisam disso. E, por default, é atribuída ao cache de resultados uma porção razoavelmente pequena do buffer. Provavelmente você não verá resultados tremendos a menos que expanda a alocação.

A Oracle implementou o Result Cache muito bem e ele faz exatamente o que promete. Nos meus testes iniciais, não tive problemas para obter resultados. Testei com algumas consultas para compreendê-lo bem e observei uma boa melhoria nos tempos de consulta.

Depois que aumentei o número de consultas e criei parâmetros, porém, não notei as mesmas mudanças da primeira vez. Mas não é algo inesperado e não representa qualquer tipo de deficiência do recurso. Só estou ressaltando que você precisa planejar com cuidado e testar a fundo antes de implementá-lo em produção.

Também não é preciso dizer que este recurso visa a aprimorar a performance de sistemas com limite de disco [disk-bound]  e não funcionará para sistemas com limite de memória [memory-bound]. Se você já está sofrendo pressão de memória, sobrecarregar um buffer em um sistema já limitado só vai piorar as coisas.

Também gostaria de observar que, em geral, também não ajudará muito para suas cargas de trabalho OLTP. E, se você utilizá-lo em suas cargas de trabalho de suporte a decisão, fique atento aos resultados de consultas que está armazenando em cache. É fácil se esquecer de que até sistemas 64 bits têm limites de memória e que o cache de um resultado com 200 milhões de linhas talvez não seja o melhor uso dos seus recursos de memória.

Gosto do Result Cache pelo que chamo de “consultas chatas”, que são pesquisas que você faz para satisfazer joins ou para extrair resultados que se apóiam em varreduras de tabelas – coisas deste tipo. Mas o Result Cache é um bom recurso que lhe permitirá fazer quase tudo que você quiser.

Opinião do Leitor
Não há comentários para essa notícia
Publicidade
Publicidade
As mais lidas
60 melhores empresas de TI e Telecom para trabalhar

A elite do RH de TI e Telecom no Brasil

Computerworld e Instituto GPTW apresentam as Melhores Empresas de TI e Telecom para Trabalhar 2009.

Veja o Especial

Confira o ranking:

  1. Chemtech
  2. Kaizen
  3. Microsoft
  4. Cisco do Brasil
  5. Google Brasil
Veja o ranking completo com as 60 empresas

SLIDE SHOWS

coluna tv
Newsletters
Assine a Computerworld