O porque e onde utilizar Result Cache

É isso ai galera, tem um mês quase que não posto um assunto aqui então vamos falar da utilização da terceira cache localizada dentro da Shared Pool chamada de Result Cache. Quando lemos a palavra cache deduzimos logicamente (ou até por osmose) que refere-se área na memória, porém o que difere essa cache da Buffer Cache é que esta última sempre conterá recentes modificações dos blocos dos datafiles que foram manuseadas por algumas transações. Já a área de result cache, possuirá a resposta/resultado de uma determinada query em cache. Beleza, quer dizer então que o Oracle se acha esperto em implementar mais uma cache? Sendo assim, neste caso não poderia ser utilizada a Keep Buffer Cache buscando manter alguns objetos por mais tempo na cache? “Não vírgula seu merda ponto”.

Pra entendermos melhor o conceito de Result Cache teremos que entender como a engine do Oracle resolveria a execução de uma query sem esta feature. Basicamente ao enviar uma query para o Oracle, este irá:

  1. efetuar a análise sinatática e semântica da query;
  2. pesquisar se a query encontra-se em cache e optar pelo harde ou soft parse;
  3. carregar em cache a estrutura de metadados dos objetos envolvidos;
  4. estimar ou utilizar o melhor plano de execução para esta;
  5. utilizar um algorítmo para pesquisar se os blocos necessitados se encontram em cache ou precisará ser efetuada leitura do disco;
  6. executar a query;
  7. manipular os blocos em memória ou efetuar I/O do disco;
  8. e finalmente devolver o resultado da query para o usuário via IPC.

Estes passos acontecerão independentemente de quantas execuções seguidas forem efetuadas. Apenas será optado pelo soft parse, poderá não ser mais necessário carregar os metadados dos objetos envolvidos e a leitura dos blocos será efetuada em cache ou do disco. Com a utilização do result cache, o Oracle executará estes mesmos passos apenas na primeira execução porém a diferença é que no momento em que o plano de execução é estimado, a engine reservará o resultado da query dentro da result cache. E nas execuções seguintes, o SGBD executará os passos:

  1. efetuar a análise sinatática e semântica da query;
  2. optar pelo soft parse;
  3. utilização do plano de execução estimado anteriormente que aponta para o resultado dentro da result cache;
  4. por fim, devolverá o resultado da query para o usuário via IPC.

É simplesmente na redução destes passos e seguindo o conceito a forma para executar algo mais rápido simplesmente é não executando (não lembro quem escreveu/falou algo desse tipo) que esta feature torna-se muito útil. Eu arriscaria dizer que a utilização de result cache foi o conceito pioneiro para utilização do In-Memory Database Cache. Claro que esta nova arquitetura utiliza driver para acesso direto à área de memória, já que o conceito primário da arquitetura deste SGBD (TimesTen) é que os dados sempre estarão em memória e o resultado de uma transação será devolvido diretamente para o buffer da aplicação, sem utilização do protocolo IPC. Mas sobre In-Memory Database e TimesTen blogarei outro dia.

Beleza, agora que entendemos o conceito desta feature de cache, vamos atrás do porque e onde utilizar. Bom, esta feature deve ser utilizada em registros que são pouco e/ou raramente modificados mas muito pesquisados. Aplicações web podem se beneficiar da utilização de lookup box para retornar um conjunto de resultados que dificilmente sofrem alterações, um exemplo seria uma tela de cadastro de usuários com o lookup box possuindo conteúdo do nome dos estados Brasileiros.

Fiquem atentos que esta feature não se aplica estritamente a ambientes OLTP. Poderá ser utilizada em ambientes DSS/DW, um exemplo seriam as queries com agregações que se possuirem pouca modificação, apresentarão ganhos significativos. Porém para usufruir destes ganhos, devemos entender do negócio para garantir que esta solução seja implantada com sucesso. A configuração para utilização é bem simples (sigam o manual de Performance Guide), e eu aconselho a utilização de hint para esta feature e não a atribuição de forma automática. Como já disse antes, nós (DBAs/Desenvolvedores/Arquitetos/GPs) entendemos o comportamento do negócio e não o Oracle.

Pois é negadis, por hoje é só! Aquele abraaaaaa!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s