Este artigo pretende alertar para o cumprimento de boas práticas ao nível de programação SQL nos seus dialectos T-SQL para o caso do MS SQL Server e PL/SQL para o caso do Oracle Database, independentemente do SGBDR, estas práticas têm elevadíssimos benefícios.
Boas práticas de codificação em SQL, são muitas vezes simplesmente ignoradas, mas originam imensos custos para o projecto, aplicação ou sistema e até para a organização.
Na minha opinião, um Programador de SQL, possuir esta qualidade ou mesmo habilidade é uma atitude orientada aos objectivos, alinhamento com as necessidades do cliente ou negócio, profissionalismo e um óptimo estilo de programação em SQL e seus dialectos.
E refiro-me concretamente, no caso do Oracle à utilização de BIND VARIABLES, são fundamentais para o desempenho de um sistema.
Para se entender melhor passarei a explicar.
Imagine uma aplicação que é alvo de milhares de instruções de SQL numa tabela de Base de Dados, como as apresentadas a seguir:
SELECT u_nome, p_nome, c_postal FROM t_fornecedor WHERE id_fornecedor = 10735;
SELECT u_nome, p_nome, c_postal FROM t_fornecedor WHERE id_fornecedor = 10840;
SELECT u_nome, p_nome, c_postal FROM t_fornecedor WHERE id_fornecedor = 10987;
Cada vez que a consulta é executada, o SGBDR Oracle primeiro analisa a SHARED POOL (zona de memória) a verificar se a instrução de SQL já foi alguma vez executada. Caso tenha já tenha sido executada, o plano de execução utilizado na anterior instância é reutilizado, e a instrução de SQL é executada.
No caso da instrução de SQL não ser encontrada na SHARED POOL, o SGBDR Oracle terá executar o processo de “parsing” ou seja análise da instrução de SQL e posteriormente realizar o estudo dos vários planos de execução para encontrar o melhor plano de acordo com as suas parametrizações, antes de executar a instrução propriamente dita. Este processo denomina-se “HARD PARSE”, e para uma Base de Dados OLTP (Online Transaction Processing) poderá consumir mais tempo do que a própria instrução de SQL.
Quando é procurada na SHARED POOL a exacta correspondência de uma instrução de SQL, só instruções exactamente iguais são consideradas. Se como no exemplo das Instruções SQL acima colocadas, forem submetidas instruções de SQL únicas, em que o predicado da cláusula WHERE é sempre diferente (id_fornecedor = 10735, id_fornecedor = 10840, etc.) nunca será encontrada uma correspondência e será necessário realizar um “HARD PARSE”. O “HARD PARSE” é muito intensivo na utilização de CPU e envolve operações de como “LATCH” de chaves nas áreas de memórias partilhadas. Esta situação poderá não originar problemas num sistema com poucos dados e pouco solicitado, mas num sistema com bastantes dados, multi-utilizador e com muitas transacções e muitas delas distribuídas, poderá simplesmente colocá-lo de rastos, com centenas ou milhares de instruções a necessitarem de ser analisadas “HARD PARSE” em simultâneo. Associado a esta situação surge um problema, a contenção que é o resultado dos inúmeros “HARD PARSE” realizados, o “HARD PARSE” é imune a medidas reactivas tais como aumento da memória física, incremento do n.º de CPU’s e muitas outras mediadas de reacção. O “HARD PARSE” é um problema encontrado em muitos sistemas e aplicações empresariais.
A solução para este problema é a reutilização dos planos de execução, e esta pode ser alcançada recorrendo a “BIND VARIABLES”. As “BIND VARIABLES” não são mais nem menos do que variáveis de substituição que são colocadas nas posições dos literais (10735, 10840, 10987). Exemplo da mesma instrução, desta vez recorrendo a “BIND VARIABLE”:
SELECT u_nome, p_nome, c_postal FROM t_fornecedor WHERE id_fornecedor =: fornecedor_numero;
Exemplo de SQL PLUS
SQL> variable fornecedor_numero number
SQL> exec :fornecedor_numero := 10987
SQL> SELECT u_nome, p_nome, c_postal FROM t_fornecedor WHERE id_fornecedor =: fornecedor_numero;
É muito fácil implementar a utilização de “BIND VARIABLES” em Java, C++ C# ou mesmo em VB.net. E como disse no início este problema não é só para o SGDBR Oracle, acontece ao mesmo ao MS SQL Server ou qualquer outro SGDBR. O MS SQL Server e SQL Bind Parameters serão abordados na 2.ª parte.
Continua…
João Paulino
