3.       Sempre que possível substituir condições com OR por UNION ALL, por ex:

Obs.: Sempre que possível utilize “UNION ALL” ao invés de “UNION” pois o “UNION” gera um distinct que geralmente gera um order by o que irá gerar um custo desnecessário comparado a concatenação do “UNION ALL”.

Continua...

Performance de querys é sem dúvida uma das maiores causadoras de dor de cabeça em DBAs e afins(J), se vocês já leram algum post neste blog devem ter percebido que gosto muito deste assunto, trato diariamente com problemas deste tipo e tem alguns pontos que acho importantes de serem analisados quando falamos em análise de consultas, vou tentar explicar melhor abaixo.

Primeiro vou falar um pouco da empresa onde trabalho a, CNP-M, graças a Deus somos uma empresa certificada MPS.BR pois os processos que foram implantados nos ajudam a diminuir e MUITO possíveis problemas de performance que teríamos e que não deixamos chegar nos clientes pois param no processo de validação. Os pontos que vou mencionar abaixo servem como base para procurar possíveis problemas de performance, bom chega de conversa mole e vamos para a melhor parte(você já sabe, TSQL).

Todas as consultas abaixo foram executadas no banco AdventureWorks / SQL Server 2005.

1.       Sempre verificar o plano de execução de cada select existente no código SQL, e analisar o uso ou não uso dos índices de cada tabela pertencente a query.

2.       Verificar o uso de Functions. Caso exista alguma function envolvida no SQL analise bem a consulta e verifique se é possível alterar a consulta para fazer um join com a própria tabela ou então até mesmo tabelas temporárias, vamos ver alguns exemplos para ficar mais fácil de entender o que estou querendo dizer.

Obs.: Atenção, o comando SET STATISTICS IO ON não leva em consideração as leituras efetuadas nas suas functions, o que certas vezes acaba gerando uma má interpretação do comando, portanto fique ligado nisso.

Continua...

Segue o post do Conor falando o que ele acha sobre Triggers.

The Trouble with Triggers

Excelente artigo.

É bom saber que não sou só eu que penso assim, não gosto de triggers e sempre que puder tentarei evita-las, não tenho isso como regra mas como base, o que é diferente.

Puts, essa foi show, eu sabia a do ALT+SHIFT + setas do teclado, mas essa do ALT + Botão Esquerdo do mouse foi sacanagem.

http://blogs.msdn.com/psssql/archive/2008/06/17/helpful-hint-making-review-of-a-query-plan-easier.aspx

É o tipo da coisa que quando você descobre logo pensa, puts e ninguém me conta?

Update:

  Aaa no Dephi e Visual Studio também funciona :-)

I’m talking with Conor about triggers, I try explain why I don’t like triggers, and how they can be bad for performance. He ask-me one sample about bad performance then I create this script on database AdventureWorks, I think he will write in your blog about triggers soon, then keep eye.

If you don’t know him, he blog on SQLSkills, do you need more? J

http://www.sqlskills.com/blogs/conor/default.aspx

IF OBJECT_ID('Production.uProduct') IS NOT NULL

  DROP TRIGGER Production.uProduct

GO

CREATE TRIGGER [Production].[uProduct] ON [Production].[Product]

AFTER UPDATE NOT FOR REPLICATION AS

BEGIN

    SET NOCOUNT ON;

    UPDATE [Production].[Product]

    SET [Production].[Product].[ModifiedDate] = GETDATE()

    FROM inserted

    WHERE inserted.[ProductID] = [Production].[Product].[ProductID];

END;

GO

-- Here we have one column called ModifiedDate, and one trigger to update this column.

SELECT ModifiedDate, *

  FROM Production.Product

 WHERE ProductID = 316

-- Now if I update the column Name of the product, the trigger will update the column

-- ModifiedDate with the GetDate()

SET STATISTICS PROFILE ON

SET STATISTICS IO ON

UPDATE Production.Product

   SET Name = 'New Blade'

 WHERE ProductID = 316

--Table 'Product'. Scan count 0, logical reads 6, physical reads 4, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

--Table 'Product'. Scan count 0, logical reads 2, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

SET STATISTICS IO OFF

SET STATISTICS PROFILE OFF

-- Whats happened here? First the Update will search for the clustered Index,

-- then the Trigger will do the same thing again. On the other hands,

-- 2 scans on table Product

IF OBJECT_ID('Supper_UpdateProduct') IS NOT NULL

  DROP PROC dbo.Supper_UpdateProduct

GO

-- Now lets go create one Stored Procedure to Update the Name and ModifiedDate of the Product

CREATE PROC dbo.Supper_UpdateProduct (@NewName nVarChar(50) = '', @ProductID Int = 0)

AS

BEGIN

  IF @ProductID = 0

  BEGIN

    UPDATE Production.Product

       SET Name = NewID(),

           ModifiedDate = GetDate()

  END

  ELSE

  BEGIN

    UPDATE Production.Product

       SET Name = @NewName,

           ModifiedDate = GetDate()

     WHERE ProductID = @ProductID

  END

END

GO

DISABLE TRIGGER Production.uProduct ON Production.Product;

GO

SET STATISTICS PROFILE ON

SET STATISTICS IO ON

EXEC dbo.Supper_UpdateProduct @NewName = N'My New Blade', @ProductID = 316

--Table 'Product'. Scan count 0, logical reads 6, physical reads 4, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

SET STATISTICS IO OFF

SET STATISTICS PROFILE OFF

GO

-- And now whats happened? The update search for the clustered index only one time.

ENABLE TRIGGER Production.uProduct ON Production.Product;

GO

-- Now imagine one worst case,

BEGIN TRAN

GO

SET STATISTICS IO ON

GO

ENABLE TRIGGER Production.uProduct ON Production.Product;

GO

UPDATE Production.Product

   SET Name = NEWID()

GO

/*

Table 'Product'. Scan count 1, logical reads 2075, physical reads 4, read-ahead reads 26, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

Table 'Product'. Scan count 1, logical reads 1052, physical reads 1, read-ahead reads 6, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

Table 'Worktable'. Scan count 0, logical reads 0, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

*/

DISABLE TRIGGER Production.uProduct ON Production.Product;

GO

EXEC dbo.Supper_UpdateProduct

GO

/*

Table 'Product'. Scan count 1, logical reads 2078, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

*/

ROLLBACK TRAN

Depois de ler um post no fórum do MSDN, resolvi escrever um pouco sobre índice, especialmente sobre o Índice Cluster que na maioria das vezes acaba sendo nossa primary key.

Vou começar com os 3 pontos que sempre são vistos em ppts de WebCasts e apresentações de boas práticas em criação de índices.

Índices cluster devem ser:

·         Únicos

o   Quando uma tabela possui um índice cluster ele servirá como referência(lookup) para todos os índices non-cluster, isso significa que quando você faz uma consulta que utiliza seu índice non-cluster e ele necessita de alguma informação que não está no próprio índice(colunas informadas na criação do índice) ele irá para o índice cluster ler esta informação, por isso ele grava o valor do seu índice cluster no índice non-cluster para conseguir fazer este lookup. É importante dizer que o SQL Server não obriga que seu índice cluster seja único, porém caso ele não seja único o SQL irá “unificar” sua chave incluindo uma informação integer de 4 bytes afim de que ele se torne único. Portanto se o SQL tiver que incluir esta informação de 4 bytes alem de consumir recurso para gerar esta informação(para cada insert ou update ele terá que verificar se esta informação já existe para saber se ele tem que incluir os 4 bytes ou não) complementar ao seu índice, ele irá ocupar mais espaço por conta dos 4 bytes para cada linha duplicada. Seus updates e inserts irão sofrer as conseqüências de uma má escolha do índice cluster.

·         Pequenos

o   Sabendo que a chave do índice cluster é salvo em todos índices non-cluster significa que quanto menor ele for menos espaço você irá utilizar para guardar esta informação no índice non-clustered. Por exemplo imagine que você possui uma tabela com uma chave primária com as colunas ID, Ano, Mes, Dia e possúi vários índices non-cluster em outras colunas, o SQL irá gravar os dados de ID, Ano, Mês, Dia em cada índice non-clustered de sua tabela. Então se ele for muito grande você terá uma grande perda de espaço e custo para seus selects(pois ele terá que ler mais páginas de dados para retornar sua informação), inserts e updates...

o   Quanto maior for seu índice cluster mais espaço seus índices non-clusters irão ocupar.

·         Estáticos

o   Deve ser estático porque se você alterar seu valor ele terá que alem de alterar o valor na tabela alterar todos os índices non-clustered lembra que ele também fica gravado nos índices non-clustered?. Outra coisa importante é que como o índice está ordenado pela chave caso o valor mude ele irá causar fragmentação na sua tabela.

Bom com base nestas informações eu tento sempre utilizar o seguinte padrão, colunas Identity para minha chave primária, elas definitivamente são Unicas, Pequenas(Integer = 4 bytes), e estáticas. Algumas vezes o máximo que tenho que fazer é mudar meu índice cluster para outra coluna que também será um identity por exemplo uma foreign key, e então definir minha chave primária como non-clustered.

Algumas pessoas podem dizer que colunas identity como primary key podem causar hot-spot, um hot-spot acontece quando existe um GRANDE número de inserts no final de uma tabela, isso pode causar Page Level Lock porque existem vários usuários tentando acessar a mesma página(final da tabela) para inserir seus dados. Sinceramente eu nunca vi isso acontecer e imagino que você vai ter que efetuar MUITOS inserts ao mesmo tempo para ver isso acontecer, portanto esse contra muitas vezes pode ser ignorado visto os benefícios do identity.

Como sempre, gosto de ver na prática(código) o que escrevo portanto vamos a parte legal da coisa, scripts.

USE Master

-- Caso exista um banco chamado Teste, apaga ele.

Já está disponível para download o Vídeo da WebCast.

Basta clicar no link e seguir os passos de inscrição.

https://msevents.microsoft.com/cui/r.aspx?t=5&c=pt-br&r=1297386063

Hoje fiz a WebCast de Caminhos para SQL Serve 2008, apesar de ter ficado nervoso no inicio foi um prazer e espero que seja a primeira de muitas.

Obrigado ao Luciano Moreira pelo apoio, Daniel pelo Convite e Leandro pelo suporte.

Segue o link para download do PPT que usei na WebCast de hoje. Assim que o vídeo estiver disponível coloco o link aqui no Blog.

God bless!