Shared Pool - Estruturas de Memória no Oracle

#23
O Shared Pool é considerada umas das estruturas de memórias mais complexas da SGA, ela é dividida em dezenas de subestruturas e todas são gerenciadas internamente pelo Oracle. Mas nesse momento vamos citar apenas os 4 principais componentes desta estrutura, as demais serão analizadas posteriormente.

Quando uma aplicação executa uma DML, vários processos internos no Oracle são realizados até o retorno do resultado para o usuário. E esses 4 componentes tem participação direta na execução da DML e com isso gerando um bom desempenho do banco de dados.

Os 4 principais componentes são:
- O Cache de Biblioteca
- O Cache de Dicionário de Dados
- A Área PL/SQL
- O Cache de Resultados de Funções PL/SQL e Consultas SQL


Agora, vamos conhecer um pouco mais de cada um.

- O Cache de Biblioteca (library cache)

Todas instruções DML enviadas pela aplicação devem ser analizadas pelo Oracle. Quem realiza essa análise é o parse, o parse converte o código escrito pelos programadores em algo executável pelo banco de dados, esse é um processo que o Oracle faz por demanda e é um processo demorado, por isso, assim que o código é analisado pelo parse ele é armazenado no Shared Pool, desta forma ele pode ser reutilizado sem a necessidade de ser reanalisado e isso melhora muito o desempenho. O algoritmo usado para localizar a SQL no Cache da Biblioteca é baseado no valores ASCII dos caracteres que compoem a instrução, isso garante que simples mudanças no SQL faz com que ela seja analisada novamente.

As verificações do parse incluem, qual é o tipo de consulta, se esta acessando uma tabela, uma view, ou outros, verifica também os valores de retorno e as permissões do usuário, resolvidos essas verificações é decidido a melhor maneira e mais rápida de se executar a consulta, essa decisão leva em consideração os indices das colunas. Para se realizar todas essas verificações e validações o parse faz diversas consultas ao dicionário de dados e essa analise pode demorar mais do que a execução da SQL em si. Por isso essa analise é registrada no Cache de Biblioteca, desta forma somente a primeira consulta demora, na segunda vez a consulta é executada imediatamente. E em aplicações bem planejadas, essa consulta pode ser analisada somente uma vez e executada milhões de vezes.

- O Cache de Dicionário de Dados

O seu Cache é criado sobre as consultas realizadas no Dicionário de Dados, o Cache de Dicionário de Dados armazena as definições dos objetos usados recentemente, que podem ser, descrições de tabelas, indices, usuários e outras definições de metadados. Esse Cache pode ser acessado por todas as sessões, desta forma diminui o acesso das sessões ao disco para ler o Dicionário de Dados, com isso otimiza a analise de uma SQL pelo Parse que pode acessar a informação do Dicionário de Dados armazenado diretamente na memória.

Mesmo se forem executadas SQLs diferentes sobre a mesma tabela, o tempo da consulta é otimizado, pois, a descrição da tabela, colunas, indíces e usuários já estão na memória.

- A área PL/SQL

PL/SQL são procedures, funções, procedures e funções empacotadas, definições de tipo de objeto e triggers, todos estão armazenados no Dicionário de Dados como código-fonte e na sua forma compilada. Quando um objeto PL/SQL é chamado pela primeira vez, ele é lido diretamente do disco do Dicionário de Dados e armazenado na Área PL/SQL do Shared Pool, quando o objeto for chamado novamente a consulta é realizada diretamente na memória, ocasionando assim consultas muito mais rápidas.

O Cache de Resultados de Funções PL/SQL e Consultas SQLs

Esse é um novo recurso oferecido a partir da versão 11g. Muitas aplicações executam a mesma consulta várias vezes, pela mesma sessão ou por sessões diferentes, com esse novo recurso o resultado é armazenado em Cache, e na próxima vez que a consulta for solicitada o servidor pode recuperar o resultado armazenado em cache. O mecanismo de cache de resultados é inteligente o bastante para saber se houve mudanças nos resultados ou permissões da tabela, se sim, a consulta é executada novamente, desta forma não há perigo de receber um resultado desatualizado do cache. Esse mecanismo é similar do cache de resultados da PL/SQL.

Por padrão o Cache de PL/SQL e consultas SQL está desativado, mas se ativado pode melhorar e muito o desempenho. Diferentemente das demais estruturas de memória do Shared Pool, esse Cache de resultados proporciona algum controle ao DBA onde é possível especificar uma tamanho máximo.


Como se pode observar, cada componente utiliza o outro componente e com isso melhora o desempenho das instruções DML. O dimensionamento do Shared Pool é crítico para o desempenho do banco de dados, o tamanho do Shared Pool deve ser o suficientemente grande para armazenar em cache todos os códigos executados com frequência e as definições de objetos necessários. Um Shared Pool pequeno diminui o desempenho, porque as sessões do servidor precisam repetidamente alocar espaço para analisar as instruções, que serão sobrescritas por outras instruções que precisam ser analisadas novamente quando forem reexecutas. Se um Shared Pool for muito grande também gera um impacto ruim no desempenho, porque se torna muito demorado pesquisá-lo.

Para realocar a memória de forma inteligente o Shared Pool utiliza o algoritmo LRU (menos usado recentemente), quando o servidor precisa de espaço no Shared Pool, o LRU procura pelo objeto que não esta sendo usado a mais tempo e libera o espaço, se esse objeto sobrescrito for utilizado novamente, então ele é alocado novamente e possivelmente,sobrescrevendo outro objeto.

A partir da versão 9i do banco de dados, o Shared Pool pode ser redimensionado para mais ou para menos a qualquer hora, esse redimensionamento pode ser manual ou apartir da versão 10g automático de acordo com a carga de trabalho, mas o mecanismo automático deve estar ativado.

Se tiverem dúvidas realizem um INSERT nos comentários e depois dê um COMMIT que depois respondo.

Abraço e bons estudos.