Este é um post disponível para assinantes MVPEste post também está disponível para assinantes da SQL Magazine DIGITAL ou para quem possui Créditos DevMedia. Clique aqui para saber mais!
dê seu feedback
post favorito
Escrevendo queries otimizadas - SQL Magazine 84
O artigo descreve as principais técnicas associadas à escrita de queries otimizadas, mostrando estruturas que devem ser evitadas dentro das consultas por as tornarem menos eficazes.
SQL Magazine 84
[Artigo já está disponível no Leitor Digital DevMedia®. Clique aqui para acessá-lo]
> Clique aqui para ler todos os artigos da SQL Magazine 84
[Artigo já está disponível no Leitor Digital DevMedia®. Clique aqui para acessá-lo]
> Clique aqui para ler todos os artigos da SQL Magazine 84
Escrevendo queries otimizadas
Mobilizando o banco para performance – Parte 1
Existem diversos pontos críticos que podem causar problemas de lentidão em um sistema, e estes, geralmente são difíceis de serem diagnosticados rapidamente com precisão. É muito comum situações de “stress tecnológico” dentro de uma empresa causada por lentidões aparentemente inexplicáveis em um ambiente estável. Geralmente isto ocorre sem que nenhuma parte envolvida no ciclo de vida e manutenção desse sistema tenha declarado novas implementações que poderiam ser apontadas como potenciais causadoras do problema e passíveis de uma investigação direcionada. Quando isso acontece em uma empresa sem uma política de desenvolvimento de software, sem controle e documentação de toda alteração realizada pelas equipes de Redes e Banco de Dados, começa uma corrida desordenada para solucionar o problema, com as áreas mirando para encontrar uma solução sem um alvo declarado.
Para evitarmos que este tipo de problema ocorra, nesta primeira parte do artigo vamos nos concentrar na construção de queries que visam o melhor desempenho, discorrendo em uma série de boas práticas que devem ser observadas ao se elaborar uma query.
Imagine o seguinte ambiente fictício: determinado dia, ao chegar ao trabalho, o DBA é interpelado pelos desenvolvedores para saber se alguma coisa estava acontecendo com o SGBD, pois o tempo de resposta de suas aplicações apresentava uma lentidão inexplicável. O DBA então verifica os logs do banco para ver se encontra alguma exceção reportada, e não encontra nada. Logo em seguida a equipe de redes é acionada para verificar se algo está ocorrendo na parte de infraestrutura, e mais uma vez nada é encontrado. E agora? O que pode estar acontecendo?
Certamente essa situação é mais comum do que se possa imaginar. Os próximos passos do DBA seriam monitorar o comportamento do banco mediante as queries enviadas pelos clientes, verificar os principais indicadores de performance e separar os SELECTs que estão demorando a retornar resultado. Mediante esta situação brevemente exposta de baixo desempenho, seguem algumas orientações de procedimentos a serem adotados para evitar esse problema.
O tempo de resposta de qualquer query é apenas um sintoma, não significa que determinada query está lenta. Para mensurar se realmente essa query é problemática seria necessário analisar: Ela está em concorrência? Em LOCK? Ou mal elaborada mesmo?
Tenha cautela na utilização de cursor. Este é um dos recursos que mais degradam o banco, pois todo momento que o cursor faz um FETCH, ele roda a query novamente. Agora imagine isso em tabelas de mais de um milhão de registros. Será mais trabalhoso pensar na lógica para substituir o cursor, mas isso pode ser feito utilizando outros recursos dentro da PROCEDURE, como expressões lógicas de loop e também trabalhando com os comandos SELECT...INTO, INSERT...INTO.
"
ATENÇÃO! A exibição deste artigo foi interrompida.
Este é um post disponível para assinantes MVP
Mobilizando o banco para performance – Parte 1
Existem diversos pontos críticos que podem causar problemas de lentidão em um sistema, e estes, geralmente são difíceis de serem diagnosticados rapidamente com precisão. É muito comum situações de “stress tecnológico” dentro de uma empresa causada por lentidões aparentemente inexplicáveis em um ambiente estável. Geralmente isto ocorre sem que nenhuma parte envolvida no ciclo de vida e manutenção desse sistema tenha declarado novas implementações que poderiam ser apontadas como potenciais causadoras do problema e passíveis de uma investigação direcionada. Quando isso acontece em uma empresa sem uma política de desenvolvimento de software, sem controle e documentação de toda alteração realizada pelas equipes de Redes e Banco de Dados, começa uma corrida desordenada para solucionar o problema, com as áreas mirando para encontrar uma solução sem um alvo declarado.
Para evitarmos que este tipo de problema ocorra, nesta primeira parte do artigo vamos nos concentrar na construção de queries que visam o melhor desempenho, discorrendo em uma série de boas práticas que devem ser observadas ao se elaborar uma query.
Imagine o seguinte ambiente fictício: determinado dia, ao chegar ao trabalho, o DBA é interpelado pelos desenvolvedores para saber se alguma coisa estava acontecendo com o SGBD, pois o tempo de resposta de suas aplicações apresentava uma lentidão inexplicável. O DBA então verifica os logs do banco para ver se encontra alguma exceção reportada, e não encontra nada. Logo em seguida a equipe de redes é acionada para verificar se algo está ocorrendo na parte de infraestrutura, e mais uma vez nada é encontrado. E agora? O que pode estar acontecendo?
Certamente essa situação é mais comum do que se possa imaginar. Os próximos passos do DBA seriam monitorar o comportamento do banco mediante as queries enviadas pelos clientes, verificar os principais indicadores de performance e separar os SELECTs que estão demorando a retornar resultado. Mediante esta situação brevemente exposta de baixo desempenho, seguem algumas orientações de procedimentos a serem adotados para evitar esse problema.
O tempo de resposta de qualquer query é apenas um sintoma, não significa que determinada query está lenta. Para mensurar se realmente essa query é problemática seria necessário analisar: Ela está em concorrência? Em LOCK? Ou mal elaborada mesmo?
Tenha cautela na utilização de cursor. Este é um dos recursos que mais degradam o banco, pois todo momento que o cursor faz um FETCH, ele roda a query novamente. Agora imagine isso em tabelas de mais de um milhão de registros. Será mais trabalhoso pensar na lógica para substituir o cursor, mas isso pode ser feito utilizando outros recursos dentro da PROCEDURE, como expressões lógicas de loop e também trabalhando com os comandos SELECT...INTO, INSERT...INTO.
"
ATENÇÃO! A exibição deste artigo foi interrompida.
Este é um post disponível para assinantes MVPEste post também está disponível para assinantes da SQL Magazine DIGITAL ou para quem possui Créditos DevMedia. Clique aqui para saber mais!
Você está em:
canal SQL
Publicidade
Jean Claudio Sousa Santos
Space do autor
Pós-graduado em Banco de Dados atua há mais de oito anos como DBA no Departamento de DST/AIDS e Hepatites Virais do Ministério da Saúde em Brasília onde também é gerente da área de Banco de Dados que se divide em: Administração de Banco de Dados, Administração de Dados e Business Intelligence, utili...
Space do autor
0
0
