Teste de Perfomance em Inserts via Aplicação x Stored Procedures

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.

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 !

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!

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!

Trabalhando com Datas no SQL Server

Um assunto muito recorrente nos fóruns de discussão, é o tratamento de campos de data/hora no SQL Server.

O problema basicamente se resume a dois pontos:
- passagem de parâmetros para um comando SQL;
- exibição de data/hora em algum formato específico.

Sobre a passagem de parâmetros, o formato padrão do SQL Server é o americano (USA): mm/dd/yyyy. Desta forma, 10/04/2007 seria dia 04 de Outubro de 2007.

Ainda sobre a passagem de parâmetros, ela se dá em 2 momentos:
- através da aplicação (Delphi, VB, etc.);
- via T-SQL, em stored procedures, triggers, por exemplo.

Eu diria que na passagem de parâmetros via aplicação - utilizando os recursos normais dos componentes de acesso a dados - não há com o que se preocupar, uma vez que o componente de acesso a dados vai se encarregar de fazê-lo, e informar o parâmetro no formato devido.

E por último, quando houver necessidade de informar uma data manualmente, "na unha", eu sugeriria fazê-lo da seguinte forma, utilizando o exemplo acima: "dd-mes-yyyy".

Ex.:

SELECT *
FROM Pedidos
WHERE DataPedido BETWEEN '01-oct-2007' AND '31-dec-2007'

Percebam que eu coloquei o nome do mês, de forma abreviada (em inglês). É isto mesmo !
Faz 10 anos que esta fórmula tem dado certo para mim... por isso a recomendo.

Não preciso me preocupar com barras ou se a primeira parte é o mês ou dia... passo desta forma e está resolvido.

Ok, uma vez que a passagem de parâmetros está esclarecida, vamos a segunda parte: a exibição.

Em primeiro lugar, gostaria de colocar que se tem alguém que deve se preocupar com exibição de datas, o responsável é a aplicação front-end.

Banco de dados não foi feito pra formatar datas e/ou números. Banco de dados foi feito pra armazenar dados, e retornar, da forma mais rápida possível e confiável.

Porém, às vezes, desejamos efetuar um SELECT e imprimir o resultado, precisamos formatar as datas.

Aí vai a dica: converta o campo data/hora para texto.

Ex.:

SELECT CONVERT(VARCHAR(20), GETDATE(), 101) AS Data

Notem o 3o. parâmetro - código 101.

No BOL (Books OnLine) existe uma tabela de códigos para este parâmetro, que vai de 101 até 130.

O padrão britânico/francês, por exemplo, que possui o formato mais próximo do nosso (dd/mm/yy), é o código 103.

Teste os formatos e encontre o mais apropriado para sua necessidade.

Abraços e até a próxima!

SQL 2005 Cumulative Update Package #4

A Microsoft liberou em 17 de outubro de 2007, um novo pacote de atualizações acumuladas para o banco de dados SQL 2005 (após o Service Pack 2).

A maioria dos bugs corrigidos estão relacionados a ferramentas auxiliares do SQL, tais como Integration Services, Analysis Services, ou ainda, recursos menos utilizados, como replicação e database mirroring.

Porém, um bug em particular chamou a atenção, foi o de 50001716, que foi identificado por deixar as queries mais lentas do que na versão 2000, quando utilizado o operador LIKE. Segundo a Microsoft, o engine escolhe a versão sub-otimizada do plano de execução quando encontra este operador.

Segue link para mais detalhes.

http://support.microsoft.com/kb/941450/LN/

Versão do SQL e Service-Pack aplicado

Ok, você executou o comando SELECT @@VERSION e o resultado não foi muito claro...

Segue link para uma tabela/lista das versões e service-packs do SQL Server (todas as versões).

http://www.sqlsecurity.com/FAQs/SQLServerVersionDatabase/tabid/63/Default.aspx

SQL Server 2005

Você ainda não migrou seu banco de dados para a última versão do Microsoft SQL Server ?

Não sabe o que está perdendo...

O SQL Server 2005 está mais robusto, mais confiável, mais seguro, e ainda mais fácil de usar !

Para pequenos negócios (databases até 4Gb), a versão SQL 2005 Express Edition é gratuita.

Para quem está achando que estou ganhando comissão da Microsoft para vender seu produto, está enganado, somente gostaria de comentar que não precisei modificar uma única linha sequer das minhas aplicações Delphi (com ADO) para rodar a nova versão.

Apenas tive que padronizar os JOINS dos comandos SELECT para se adequar ao SQL ANSI 92, porque a versão 2005 não aceita mais o comando "*=" para designar um LEFT OUTER JOIN. Agora você deve especificar a cláusula FROM corretamente.

No mais, nenhuma dificuldade.

Consulte as TOP 30 Features do produto no site da Microsoft.
http://www.microsoft.com/sql/prodinfo/features/top30features.mspx

Script para Reindexar Tabelas e Liberar Espaço

Utilizo o script abaixo para verificar o status de todas as tabelas de um database, reindexar os índices das mesmas, e atualizar o espaço utilizado pelos índices.

Na primeira parte, identifico o nome do database e salvo em uma variável, para uso mais adiante.

O conceito do script baseia-se num cursor, criado a partir da lista de tabelas, armazenadas na tabela do sistema SysObjects (se preferir, utilize as tabelas do Information_Schema).

O comando para verificar a tabela, é o "dbcc checktable".
Detalhe importante: o database precisa estar em modo SINGLE_USER para este comando ser executado com sucesso.

O comando para reindexar a tabela é o "dbcc dbreindex".

O comando para atualizar o espaço utilizado é o "dbcc updateusage".

Consulte o BOL para sintaxe dos parâmetros.

Para usá-lo, abra o Query Analyzer, e posicione no database desejado.
Ou acrescente na primeira linha, o comando USE, para selecionar o database, caso necessite executar a partir do utilitário O-SQL.

-- Inicio
DECLARE @DsDatabase SYSNAME
SELECT @DsDatabase = D.Name
FROM Master..SysProcesses P, Master..SysDatabases D
WHERE P.Dbid = D.Dbid
AND P.Spid = @@Spid

DECLARE @NomeTabela VARCHAR(80)
DECLARE CursorTabelas CURSOR FAST_FORWARD
FOR
SELECT DISTINCT CONVERT(VARCHAR(80), T.Name) AS Objeto
FROM SysObjects T, SysIndexes I
WHERE T.Type = 'U'
AND I.Id = T.Id
ORDER BY Objeto
OPEN CursorTabelas
FETCH NEXT FROM CursorTabelas INTO @NomeTabela
WHILE @@fetch_status = 0
BEGIN
PRINT 'Reindexando tabela ' + @NomeTabela + '...'
IF (SELECT DATABASEPROPERTYEX (@DsDatabase, 'UserAccess')) = 'SINGLE_USER'
DBCC CHECKTABLE (@NomeTabela, REPAIR_ALLOW_DATA_LOSS)
DBCC DBREINDEX (@NomeTabela)
DBCC UPDATEUSAGE (@DsDatabase, @NomeTabela)
FETCH NEXT FROM CursorTabelas INTO @NomeTabela
END
CLOSE CursorTabelas
DEALLOCATE CursorTabelas
-- Fim

Início

Olá a todos!
Sou programador SQL Server e Delphi há 10 anos e a internet sempre foi uma fonte riquíssima de recursos - leia-se Google ;)
Portanto, decidi criar este espaço para compartilhar meu humilde conhecimento em desenvolvimento de software, e ouvir novas opiniões.

Espero que gostem, comentem por favor!

Atualmente, dirijo uma empresa de desenvolvimento de software sob medida, ou seja, no jargão da área, uma fábrica de software. Fazemos o sistema conforme as necessidades do cliente, "pacote" aqui nem pensar...

Visite: http://www.mdssistemas.inf.br/

Entre em contato: periclessevegnani@yahoo.com.br