Written by: Banco de Dados

Problemas de performance em bancos de dados

Muitas de nossas aplicações podem estar perdendo qualidade por falta de conhecimento de algumas particularidades do SQL SERVER. Segue algumas dicas que podem melhorar em muito a performance de nossas aplicações:

Clique para expandir:

Problemas de performance em bancos de dados Nunca usar o prefixo SP_ em stored_procedures

Exemplo: SP_CADASTRO_CLIENTES

De que forma o sql interpreta uma stored procedure com o prefixo SP_?

Quando uma procedure é precedida por SP_ o SQL Server busca a procedure no banco Master.
Isso permite que sejam criadas procedures globais para administrar o servidor.
Essas procedures podem ficar no Master e serem chamadas a partir de qualquer banco que o SQL Server as encontra.

Então por que não devemos nomear todas nossas procedures como SP_ ?

O SQL Server mantém um cache de planos de execução das procedures.
Assim sendo, quando uma aplicação executa uma procedure, primeiramente ele procura esta procedure no cache.
Se estiver lá utiliza estas informações, caso contrário terá que recompilar.
A versão 7 e superiores mantém apenas 1 cópia de cada procedure no cache de procedures.
Para garantir isso o SQL Server precisa ter certeza que, recebendo 2 pedidos simultâneos para a mesma procedure, não tentará compila-la 2 vezes.
Assim sendo, durante o processo de compilação o SQL Server gera um lock, chamado de compilation lock, que impede que outras aplicações compilem a procedure ao mesmo tempo.
Ocorre que o compilation lock é gerado imediatamente após a procura no cache.
Isto faz com que o SQL Server busque a procedure no cache, e se não achar, gera o lock.

No que isto interfere no desempenho?

Quando a procedure tem o prefixo SP_ ela é primeiramente procurada no Master e não no banco em que o usuário está.
Quando a procedure não é encontrada no Master é gerado o compilation lock.
Posteriormente, antes de compilar a procedure, o SQL Server acaba descobrindo que ela já está no cache de procedures do banco de dados do usuário e reaproveita o cache, sem recompilar a procedure.
Porém TODAS as chamadas desta procedure vão gerar o compilation lock e prejudicar seriamente o tempo de execução da procedure.
Devido a isso, evite utilizar o prefixo SP_ nas suas procedures, utilize apenas quando necessário, para procedures administrativas.

Problemas de performance em bancos de dados Utilizar Set NoCount On nas procedures

O Set Nocount On é uma instrução que, quando utilizada nas procedures, garante uma melhor otimização, pois evita que a contagem de registros afetados, aquela que normalmente é mostrada pelo query analyzer, seja gerada e transmitida pela rede.
A tabela syscomments contém o código fonte de todas as procedures geradas, e através dela é possível encontrar procedures que não estejam utilizando Set NoCount On.
Através desta query, obtemos as procedures que precisam ser alteradas:

select    name from    syscomments a,    sysobjects b where    a.id=b.id and    b.xtype=’P’ and  not exists (select id from syscomments where text like ’%set%nocount%on%’ and id=a.id) order by    name 

Problemas de performance em bancos de dados Evitar a utilização de cursores

Cursores geram grande prejuizo para a performance. Deve-se verificar as procedures que fazem uso de cursores e analisá-las para garantir que não existe nenhuma forma alternativa de escrevê-las. Esta query busca as procedures que utilizam cursores:

select    a.id,    b.name from    syscomments a,    sysobjects b where    a.id=b.id and    a.text like ’%open %’ 

Problemas de performance em bancos de dados Identificar procedures que estejam utilizando UNION sem ALL

A falta do ALL no UNION dificulta uso de índices e prejudica a performance da aplicação. Rode esta query para identificar procedures que precisam ser corrigidas:

select    a.id,    b.name from    syscomments a,    sysobjects b where    a.id=b.id and    a.text not like ’% UNION ALL%’ and    a.text like ’% UNION %’ and    b.xtype=’P’ 

Problemas de performance em bancos de dados Identificar procedures que estejam fazendo montagem e execução de strings

A montagem e execução de strings é extremamente prejudicial para a performance, pois o SQL Server só é capaz de determinar como a execução será feita em run-time. Quando existe alternativa, é preferível evitar isso. Para identificar procedures nesta condição, rode esta query:

select    a.id,    b.name from    syscomments a,    sysobjects b where    a.id=b.id and    (a.text like ’%EXEC(%’ or a.text like ’%execute(%’) 

Problemas de performance em bancos de dados Cuidado com os Triggers

Os triggers são os objetos mais delicados para o processo de transferência. Isso porque o trigger não é claramente visivel entre os objetos do banco de dados (via enterprise manager) e a falta do trigger não faz com que a aplicação pare de funcionar de imediato. Por isso não é raro acontecer de na implantação da aplicação um trigger ser esquecido para trás e a falta dele só ser notada tempos depois da aplicação já estar funcionando. Deve-se, então, ter extremo cuidado com os triggers, garantindo que nenhum seja esquecido para trás. Uma solução é fazer uma query que crie uma listagem de todos os triggers existentes no banco e suas respectivas tabelas. Executando a query nos dois bancos pode-se com certa facilidade verificar se todos os triggers estão presentes ou não. Considerando que na metodologia de desenvolvimento para banco, o uso de triggers é exceção e não regra, têm-se poucos triggers a avaliar.

Para obter uma listagem dos triggers e suas respectivas tabelas, rode esta query :

 select    name,    object_name(parent_obj) tabela  from    sysobjects where    xtype=’TR’  

Veja também


    Conexão ao MySQL

    Para conectar via JDBC, utilize o seguinte código como exemplo:

    Class.forName("org.gjt.mm.mysql.Driver");  Connection con = DriverManager.getConnection("jdbc:mysql://<IP do MySQL>/seu_login?autoReconnect=true", "seu_login", "senha_do_banco");  

    Para maior segurança, o acesso remoto direto ao MySQL via internet não está aberto, mas você pode gerenciar sua base via web utilizando o nosso aplicativo de gerenciamento. Para isso, siga as instruções abaixo:

    Problemas de performance em bancos de dados Acesse o Painel de Controle com o seu usuário e senha,

    Problemas de performance em bancos de dados Em Hospedagem de Sites, clique em Gerenciar hospedagem localizado à direita do login de ftp da hospedagem contratada.

    Problemas de performance em bancos de dados Em Banco de dados MYSQL dentro de Serviços Inclusos ao Plano, clique no botão Gerenciador MYSQL.

    Observação
    O servidor MySQL encontra-se separado do servidor Web o que melhora a performance e estabilidade do seu site.

    Conexão ao PostgreSQL

    Para conectar via JDBC, utilize o seguinte código como exemplo:

    Class.forName("org.postgresql.Driver");  Connection con = DriverManager.getConnection("jdbc:postgresql://<IP do PostgreSQL>/seu_login", "seu_login", "senha_do_banco");  
    Observação
    O servidor PostgreSQL encontra-se separado do servidor Web o que melhora a performance e estabilidade do seu site.

    Conexão ao SQL Server

    Para conectar via JDBC, utilize o seguinte código como exemplo:

    Class.forName("com.jnetdirect.jsql.JSQLDriver");  Connection con = DriverManager.getConnection("jdbc:JSQLConnect://<IP do SQL Server>/seu_login", "seu_login", "senha_do_banco");  
    Observação
    O driver JDBC para SQL Server é um driver profissional JDBC 3.0 que suporta toda as funcionalidades do SQL Server como chamadas a stored procedures e caracteres em português.

    Lembramos que por padrão não é possível conectar-se a bases externas através de JSP em ambiente compartilhado, somente em JVM Dedicado. Caso você possua o JSP em ambiente compartilhado e necessite dessa conexão, abra um chamado em nosso HelpDesk, na categoria “JSP, Java Servlets” descrevendo como funcionará sua aplicação.

    Veja também


    Visited 1 times, 1 visit(s) today
    Era isso que estava procurando?
    SimNão
    Last modified: 12 de julho de 2024