Artigo no estilo Mentoring

Mentoring:Este artigo apresenta como podemos ganhar desempenho através do uso de bind variables em consultas SQL. Para isso, será apresentado um exemplo real de consulta que apresenta problemas de performance e analisaremos como o SGBD se comporta considerando diferentes cenários de solução: literais, variáveis de substituição e bind variables.

Será discutido o impacto de cada opção no processamento das consultas escritas. Essa discussão é útil nas atividades diárias de um DBA. A otimização do desempenho do banco é uma de suas principais atribuições. Fazer este tipo de ajuste diretamente nas consultas muitas vezes traz um ótimo resultado.

A cada vez que uma instrução SQL é enviada ao banco de dados, uma busca exata do texto é realizada para verificar se a instrução já existe na shared pool (ou seja, se a instrução já foi executada previamente).

A Shared Pool foi introduzida como uma funcionalidade do Oracle na versão 7, inicialmente como sendo um repositório para compartilhamento de instruções SQL e códigos PL/SQL.

Desde então, mesmo que servindo a alguns outros propósitos, ainda mantém sua característica original de armazenar cursores para o compartilhamento entre as sessões conectadas ao banco de dados.

Em outras palavras, a shared pool é um cache de metadados. De um lado temos o buffer cache, que é utilizado para armazenar dados, e de outro lado temos a shared pool utilizada para armazenar objetos complexos que descrevem como os dados são armazenados, como estão relacionados com outros dados e como podem ser recuperados.

A maior utilização da shared pool se dá no suporte à execução de instruções SQL e pacotes PL/SQL compartilhados, mas para criarmos um cursor ou compilar uma procedure PL/SQL é necessário conhecer todas as informações a respeito dos objetos referenciados pela instrução ou procedure que está sendo compilada.

Por exemplo, a fim de criar um simples cursor para uma instrução SELECT em uma tabela, será necessário conhecer os metadados sobre a tabela como nome das colunas, tipos de dados, índices e estatísticas do otimizador.

Todas estas informações também estão armazenadas na shared pool, independente do cursor ou programa.

Ao fazer o cache destes metadados de forma independente, eles podem ser utilizados para construir qualquer quantidade de cursores, evitando o “trabalho extra” de consultar o dicionário de dados diversas vezes para a mesma tabela.

Em adição às instruções SQL e códigos PL/SQL compartilhados, há algumas outras áreas de memória que ocupam espaço na shared pool, onde a maioria delas também é compartilhada globalmente entre as sessões conectadas ao banco de dados. Alguns desses componentes possuem tamanho fixo, definido no momento da inicialização do banco de dados (startup), enquanto outras podem ser alteradas dinamicamente.

A grande vantagem de possuir todas estas informações armazenadas na shared pool sobre as instruções SQL ou códigos PL/SQL é a possibilidade de reutilização de planos de execução, por e ...

Quer ler esse conteúdo completo? Tenha acesso completo