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:
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.
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
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 %’
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’
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(%’)
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:
Acesse o Painel de Controle com o seu usuário e senha,
Em Hospedagem de Sites, clique em Gerenciar hospedagem localizado à direita do login de ftp da hospedagem contratada.
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
- Posso ter uma aplicação local acessando a base de dados na Locaweb?
- Posso criar um pool de conexões com banco de dados?
- Liberação de IPs ou Hostnames para acesso remoto