Olá!
Gostaria de compartilhar com os amigos um pequeno, porém significante teste feito com inserções de registros.
Meu objetivo é provar por A+B que o insert via Stored Procedure é mais rápido que o insert via aplicação.
Foram utilizados nestes testes os componentes da paleta dbGo/ADO do Delphi 7.
O banco de dados utilizado foi SQL 2005 Express SP3, rodando num laptop.
Abaixo, segue os links para você baixar a aplicação teste, bem como o script utilizado para criação de um database, uma tabela, e uma stored procedure, a serem utilizadas no seu teste.
Fiz um laço no Delphi, inserindo 10.000 registros na tabela de testes.
No primeiro teste, utilizando componente TADOQuery para fazer a inserção, levou 28 segundos.
No segundo teste, utilizando componente TADOStoredProc, levou 20 segundos.
Uma redução aí na faixa dos 30%.
Baixe a aplicação, faça o teste, e chegue as suas próprias conclusões.
Aplicação
Script
Por isso, recomendo veementemente o uso de Stored Procedures para Inserir, Excluir, Consultar, enfim, para fazer qualquer tipo de processamento que requer algum requinte de performance.
Além disto, Stored Procedures possuem as seguintes vantagens em relação a T-SQL via aplicação:
- elas permitem programação modular, ou seja, a lógica de negócio fica centralizada em um ponto, ao invés de vários pontos nas aplicações;
- elas permitem execuções mais rápidas, porque o "engine" do SQL Server otimiza sua execução e guarda no seu "cache" para futura utilização;
- elas reduzem tráfego de rede, justamente porque sua execução fica a nível de servidor, e somente o retorno é devolvido à aplicação "client";
- elas podem ser usadas como mecanismo de segurança;
- elas evitam "lock" de tabela, uma vez que o "engine" enfileira todas as chamadas que são feitas às SPs e controla sua execução.
Abraços e até a próxima.
Pericles.
This space is intended to be a channel of communication
between the enthusiasts of SQL Server.
We must be humble to recognise that we don't know everything.
In fact we know nothing... Everyday it's an opportunity to learn something new.
Questions and comments are welcome.
Contact me at
periclessevegnani@gmail.com or +55(47)999-189-109.
quarta-feira, 19 de novembro de 2008
sexta-feira, 8 de agosto de 2008
Problemas e Soluções para SQL 2005 no Vista
Estou instalando meus sistemas em alguns clientes com o Windows Vista, e minha intenção aqui é compartilhar algumas dicas sobre as dificuldades encontradas.
O caso que serviu de inspiração para este post foi com a versão Home Basic.
O serviço do SQL foi instalado nesta máquina e ela é utilizada como "servidor", onde outra estação com Windows XP a acessava.
Após instalação e liberação das devidas portas no firewall, ativação do serviço "Navegador/Browser" do SQL, o sistema entrava, localmente e remotamente.
Porém, localmente, algumas telas do sistema apresentavam uma lentidão inaceitável. Remotamente estava a 100%.
Puxei minha "cartilha" e comecei:
- atualizei o SQL Server, com o SP2:
- não resolveu.
- atualizei o Service Pack do Vista para SP1, pois era original:
não resolveu.
- revisei as configurações do Firewall, liberando a 1433 TCP e 1434 UDP e compartilhamento de impressoras (por teimosia, pois na estação remota não havia problema de acesso):
não resolveu.
- desliguei o Serviço de Indexação do Vista:
nada.
Fui embora, levei o backup da base e fui revisar minha aplicação (Delphi), na tentativa de pegar algum problema, porém... sem sucesso.
Contatei meu "brother", Microsoft MCSE, e ele deu uma dica: RSS (receive-side scaling), que é uma nova função do sistema operacional (Vista e Server 2003), que tem gerado alguns problemas.
Voltei ao cliente, decidido a desligar o tal "autotuning", aí vai o comando:
netsh interface tcp set global autotuning=disabled
Legal, mas... reiniciei e... nada, o problema continua.
Já quase desistindo, resolvi brincar com os protocolos de rede do SQL.
Fui desligando um-a-um, até chegar num denominador comum... e bingo... achei.
A única combinação que funcionou, e resolveu o problema, foi o protocolo "Named Pipes/Pipes Nomeados".
Deixei somente este protocolo ativo, e funcionou 100%, localmente e remotamente.
Fiquem à vontade para comentar o assunto, e abraços, até a próxima !
O caso que serviu de inspiração para este post foi com a versão Home Basic.
O serviço do SQL foi instalado nesta máquina e ela é utilizada como "servidor", onde outra estação com Windows XP a acessava.
Após instalação e liberação das devidas portas no firewall, ativação do serviço "Navegador/Browser" do SQL, o sistema entrava, localmente e remotamente.
Porém, localmente, algumas telas do sistema apresentavam uma lentidão inaceitável. Remotamente estava a 100%.
Puxei minha "cartilha" e comecei:
- atualizei o SQL Server, com o SP2:
- não resolveu.
- atualizei o Service Pack do Vista para SP1, pois era original:
não resolveu.
- revisei as configurações do Firewall, liberando a 1433 TCP e 1434 UDP e compartilhamento de impressoras (por teimosia, pois na estação remota não havia problema de acesso):
não resolveu.
- desliguei o Serviço de Indexação do Vista:
nada.
Fui embora, levei o backup da base e fui revisar minha aplicação (Delphi), na tentativa de pegar algum problema, porém... sem sucesso.
Contatei meu "brother", Microsoft MCSE, e ele deu uma dica: RSS (receive-side scaling), que é uma nova função do sistema operacional (Vista e Server 2003), que tem gerado alguns problemas.
Voltei ao cliente, decidido a desligar o tal "autotuning", aí vai o comando:
netsh interface tcp set global autotuning=disabled
Legal, mas... reiniciei e... nada, o problema continua.
Já quase desistindo, resolvi brincar com os protocolos de rede do SQL.
Fui desligando um-a-um, até chegar num denominador comum... e bingo... achei.
A única combinação que funcionou, e resolveu o problema, foi o protocolo "Named Pipes/Pipes Nomeados".
Deixei somente este protocolo ativo, e funcionou 100%, localmente e remotamente.
Fiquem à vontade para comentar o assunto, e abraços, até a próxima !
domingo, 29 de junho de 2008
Certificação Microsoft
É com muita alegria que compartilho mais esta conquista pessoal: aprovação na prova 70-431, que dá a certificação MCTS em SQL Server 2005.
Não foi fácil... eu já estava há alguns anos postergando a realização da prova, mas este mês fui inspirado pela minha esposa, e decidi fazê-la. Marquei a prova num ato de impulso, com menos de 15 dias pra estudar. Era agora ou nunca.
Para os que quiserem se aventurar nesta, a prova é em inglês. A minha teve 47 questões, 35 de múltipla escolha e 12 simulados.
Experiência é imprescindível, uma vez que caíram algumas questões que você não encontra resposta em livro algum, só quem já escreveu um SELECT pra "sacar" a pergunta.
Obrigado a todos que me apoiaram.
Até a próxima!
Não foi fácil... eu já estava há alguns anos postergando a realização da prova, mas este mês fui inspirado pela minha esposa, e decidi fazê-la. Marquei a prova num ato de impulso, com menos de 15 dias pra estudar. Era agora ou nunca.
Para os que quiserem se aventurar nesta, a prova é em inglês. A minha teve 47 questões, 35 de múltipla escolha e 12 simulados.
Experiência é imprescindível, uma vez que caíram algumas questões que você não encontra resposta em livro algum, só quem já escreveu um SELECT pra "sacar" a pergunta.
Obrigado a todos que me apoiaram.
Até a próxima!
quarta-feira, 28 de maio de 2008
Migrando logins entre instâncias SQL 2000
Algumas vezes precisamos migrar um ambiente para um novo servidor.
Após os procedimentos padrão:
- instalação do SQL Server no novo servidor;
- restauração do backup ou "attach" do database.
Surge então o problema: os logins e suas respectivas senhas.
A Microsoft disponibiliza no link abaixo, "receita de bolo" para a solução do problema.
Basicamente, trata-se de rodar o script mencionado no Servidor1, capturar o "result", e rodar no Servidor2.
Vale lembrar que esta solução funciona somente entre servidores 7.0 e 2000.
Link: http://support.microsoft.com/kb/246133/en-us
Abraços e até a próxima!
Após os procedimentos padrão:
- instalação do SQL Server no novo servidor;
- restauração do backup ou "attach" do database.
Surge então o problema: os logins e suas respectivas senhas.
A Microsoft disponibiliza no link abaixo, "receita de bolo" para a solução do problema.
Basicamente, trata-se de rodar o script mencionado no Servidor1, capturar o "result", e rodar no Servidor2.
Vale lembrar que esta solução funciona somente entre servidores 7.0 e 2000.
Link: http://support.microsoft.com/kb/246133/en-us
Abraços e até a próxima!
Assinar:
Postagens (Atom)