quinta-feira, 23 de julho de 2009

CTPs Julho para o Azure

Nossa, instalei ontem, sem necessidade, o CTP de junho do Azure SDK na minha nova máquina, pois já havia saído o CTP de Julho das ferramentas. Está acompanhando os CTPs? Então baixe aqui:

Windows Azure Software Development Kit (July 2009 CTP)
Ref.: http://www.microsoft.com/downloads/details.aspx?familyid=AA40F3E2-AFC5-484D-B4E9-6A5227E73590&displaylang=en

Windows Azure Tools for Microsoft Visual Studio July 2009 CTP
Ref.: http://www.microsoft.com/downloads/details.aspx?FamilyID=8d75d4f7-77a4-4adf-bce8-1b10608574bb&displaylang=en

Microsoft .NET Services SDK (July 2009 CTP)
Ref.: http://www.microsoft.com/downloads/details.aspx?FamilyID=38d8cf79-fc39-4aef-b3fd-ef280f2e9fa6&displaylang=en


[]s
Luciano Caixeta Moreira - {Luti}
Chief Innovation Officer
Sr. Nimbus Ltda
E-mail: luciano.moreira@srnimbus.com.br

terça-feira, 21 de julho de 2009

Artigo Resource Governor + plano de estudo

Hello people.

Artigo

Vi um anúncio recente de um artigo que parece ser bem bacana, falando sobre o Resource Governor. O link para o whitepaper está aqui: http://download.microsoft.com/download/D/B/D/DBDE7972-1EB9-470A-BA18-58849DB3EB3B/ResourceGov.docx
E não deixe de consultar outros whitepapers em: http://www.microsoft.com/sqlserver/2008/en/us/white-papers.aspx

Estudo

Aproveitando o gancho, vira e mexe eu recebo questionamentos sobre o que ler para aprender mais sobre o SQL Server e acabo ficando sem saber se faço uma resposta curta ou se escrevo um e-mail baleia. A resposta certa é: escolha aquele que dá certo com você!

Hoje eu dia existem tantos recursos que nenhum ser humano consegue digerir tudo o que existe. Então você deve escolher aquele que dá mais certo com o seu perfil. Vamos ao meu caso: dificilmente eu leio um livro sem interrupção (normalmente pego 3 ou 4 ao mesmo tempo), então para mim o que funciona é: ler capítulos de um livro sobre assuntos de meu interesse, intercalo isso com leitura diária de blogs (minha fonte preferida) e artigos de revistas.

Além disso existem whitepapers fantásticos publicados na Microsoft (que pouca gente lê), juntamente com a documentação dos produtos, que possuem informações detalhadas do produto. A meu ver, ambos estão quase no mesmo nível da leitura de um capítulo de um livro, então são recursos que necessitam de uma dedicação maior de tempo.

Fora a leitura, não têm mágica, é treino! Use o produto, faça testes, entenda como funciona, aí sim você vai passar a ter mais confiança no seu conhecimento. Para verificar tudo o que aprendeu, coloque em prática: dê aula, preste consultoria, use no dia-a-dia, crie material, enfim, teste o que você ACHA que sabe.

No final acabamos descobrindo que nosso conhecimento é só uma pequena gota num oceano bem, bem maior. Sempre digo isso no início dos treinamentos, principalmente de internals: É normal que você saia dessa sala achando que sabe menos do que quando entrou, pois meu objetivo é abrir ao máximo seu horizonte. :-)

Qual é o seu estilo? Descubra-o, pois ninguém conseguirá lhe dizer isso.

[]s
Luciano Caixeta Moreira - {Luti}
Chief Innovation Officer
Sr. Nimbus Ltda
E-mail: luciano.moreira@srnimbus.com.br

Minhas palestras no TechEd

Bom dia pessoal.
Ontem eu anunciei que as palestras no TechEd estavam disponíveis para consulta e hoje volto para contar para vocês quais são as minhas (já que tá todo mundo falando nos blogs por aí...).

Vou fazer uma sessão sozinho (de um tema que gosto pouco :-)):
  • Dicas e truques: Torne suas queries mais rápidas e eficientes
E outra sessão com o Gustavo Gatass, onde a descrição está para ser atualizada:
  • Data Warehouse e Integration Services numa Solução de BI

[]s
Luciano Caixeta Moreira - {Luti}
Chief Innovation Officer
Sr. Nimbus Ltda
E-mail: luciano.moreira@srnimbus.com.br

segunda-feira, 20 de julho de 2009

Bom dia Pessoal!
Na semana passada saiu a listagem completa das sessões do TechEd. Vale a pena dar uma olhada no que teremos nesse ano e reservar o seu lugar ao sol. :-)

http://www.teched.com.br/palestras.aspx

Eu estarei de volta aos palcos do TechEd, dessa vez com duas palestras na track de DBP - Plataforma de banco de dados.

Espero nos encontrarmos por lá...

[]s
Luciano Caixeta Moreira - {Luti}
Chief Innovation Officer
Sr. Nimbus Ltda
E-mail: luciano.moreira@srnimbus.com.br

sexta-feira, 17 de julho de 2009

Plano de execução + cache = DBA enganado

Bom dia pessoal, vamos de SQL Server mais uma vez?

Se você preferir ler o PDF deste artigo, pode baixá-lo aqui.




É comum termos que analisar o plano de execução de uma consulta ou procedimento em nosso banco de dados, aí utilizamos como ponto de partida os famosos STATISTICS IO, STATISTICS TIME e EXECUTION PLAN, para nos ajudar na análise, mas cuidado! Existe algo que pode atrapalhar e levá-lo a tirar conclusões erradas, quer ver?
Em primeiro lugar vamos criar o procedimento ListaPedidosData, que lista todos os pedidos a partir de determinada data:

USE Northwind
GO

IF OBJECT_ID('dbo.ListaPedidosData') IS NOT NULL
DROP PROC dbo.ListaPedidosData
GO


CREATE PROC dbo.ListaPedidosData
@odate AS DATETIME
AS
SELECT OrderID, CustomerID, EmployeeID, OrderDate

FROM dbo.Orders
WHERE OrderDate >= @odate
GO


Criado o procedimento, vamos executá-lo com um parâmetro de alta seletividade (isto é, que retorna poucos registros). Analisando o plano de execução podemos notar que o SQL Server sabiamente optou por fazer um index seek seguindo de quatro key lookups, um para cada registro retornado pelo seek (figura 01), com o seguinte custo de IO: Table 'Orders'. Scan count 1, logical reads 10.

EXEC dbo.ListaPedidosData '19980506'
GO



(Figura 01)

Agora vamos tentar chamar o procedimento com um parâmetro de baixa seletividade, que vai retornar todos os pedidos existentes na tabela (830). O que você espera desse plano de execução? Um clustered index scan, certo? Errado...

EXEC dbo.ListaPedidosData '19960101'
GO


O SQL Server também vai fazer um index seek seguindo de um key lookup (figura 01), pois ele está reutilizando um plano que está em cache e este foi definido dessa forma, então é a maneira que a consulta deve ser executada. Analisando o custo de IO temos: Table 'Orders'. Scan count 1, logical reads 1665. Um pouquinho diferente que o primeiro, certo? Esse é um dos preços que pagamos por estar reutilizando um plano da cache, ele pode não ser bom para o parâmetro atual.
Com o intuito de provar que o plano não é bom para essa seletividade, você acaba por tirar a consulta de dentro do procedimento e executá-la externamente, informando o parâmetro com baixa seletividade. O que você verá? Dessa vez acertou, um clustered index scan (figura 02), com custo de IO: Table 'Orders'. Scan count 1, logical reads 22.



(figura 02)

Pareceu bem melhor que o plano utilizado pela SP, não foi? Aí para termos certeza disso, vamos executar o procedimento e a consulta no mesmo batch e analisar o custo relativo de cada um.

EXEC dbo.ListaPedidosData '19960101'
go


SELECT OrderID, CustomerID, EmployeeID, OrderDate

FROM dbo.Orders

WHERE OrderDate >= '19960101'
go


Qual o resultado? O SQL Server mostra para você que a execução do procedimento tem um custo de 41% do batch, enquanto o scan custa os restantes 59%. Isto é, pelo que o SQL Server nos informa, é mais barato executar o primeiro do que o segundo (figura 03).



(Figura 03)


É nessa hora que você, leitor, grita: ooooohhhhhhhhhh! Eu podia apostar um pedaço do dedo que o segundo plano é o melhor e o SQL Server me diz que o custo dele é maior que o primeiro. Macacos me mordam!
Aí você sai olhando informação de IO, tempo de execução (CPU e Elapsed), custo de tudo que pode imaginar e ainda assim tudo aponta para o segundo como o melhor plano, mas o SQL Server insiste em mostrar um custo menor para o primeiro.
O que está acontecendo?
Faça o seguinte teste. Execute a dupla procedimento/consulta trocando o parâmetro do procedimento por uma série de valores aleatórios, conforme trecho de código abaixo:

-- comparando os tempos...
EXEC dbo.ListaPedidosData '20100101'

go

SELECT OrderID, CustomerID, EmployeeID, OrderDate

FROM dbo.Orders

WHERE OrderDate >= '19960101'

go


-- comparando os tempos...

EXEC dbo.ListaPedidosData '19970101'

go

SELECT OrderID, CustomerID, EmployeeID, OrderDate
FROM dbo.Orders

WHERE OrderDate >= '19960101'

go


O que você vai ver? Que TODOS os resultados relativos de custo estão na proporção 41% e 59%! Opa, então têm alguma coisa “errada”, que é o.... PLAN CACHE!

Você concorda que o otimizador de consultas do SQL Server utilizou uma série de estatísticas para gerar o plano que foi colocado em cache? Não iria fazer muito sentido se a cada execução o SQL Server ficasse estimando novos custos de acordo com os parâmetros, afinal o plano será reutilizado de qualquer forma, então porque perder tempo gerando essas informações? O que temos nos exemplos acima é o SQL Serve reutilizando o plano e também os custos estimados para a consulta original, que retornou somente 4 registros!
Faça o teste executando o script abaixo:

-- Execute os dois juntos SELECT OrderID, CustomerID, EmployeeID, OrderDate FROM dbo.Orders WHERE OrderDate >= '19980506' go SELECT OrderID, CustomerID, EmployeeID, OrderDate FROM dbo.Orders WHERE OrderDate >= '19960101' go
O que você viu? Novamente a proporção 41% e 59%. Aqui faz todo o sentido do mundo, pois um o custo do primeiro é realmente menor que o do segundo. Então para verificar a real proporção entre os custos de execução vamos usar uma hint para simular o plano que está em cache (com valores atualizados) e ver o resultado...

-- Simulando o plano em cache, mas agora com valores atualizados...
SELECT OrderID, CustomerID, EmployeeID, OrderDate

FROM dbo.Orders WITH(INDEX(OrderDate))

WHERE OrderDate >= '19960101'

go


SELECT OrderID, CustomerID, EmployeeID, OrderDate
FROM dbo.Orders

WHERE OrderDate >= '19960101'

go


Como resultado, temos a figura 04.



(Figura 04)

Ah, agora sim! O primeiro tem um custo relativo de 92% enquanto o segundo têm um custo relativo de 8% no batch.
Eu escrevi tudo isso para te dizer o que?

CUIDADO COM OS PLANOS EM CACHE QUANDO ESTIVER FAZENDO A ANÁLISE COMPARATIVA DE SUAS CONSULTAS!

Os valores armazenados em cache para um parâmetro diferente do que você está utilizando serão reaproveitados na hora de mostrar o custo relativo, podendo levá-lo a tirar conclusões erradas em seu ambiente. Então durante sua análise é interessante sempre usar um DBCC FREEPROCCACHE para limpar a cache de planos e usar hints para simular planos, facilitando a comparação.

Espero que você tenha gostado...

[]s
Luciano Caixeta Moreira - {Luti}
Chief Innovation Officer
Sr. Nimbus Ltda
E-mail: luciano.moreira@srnimbus.com.br

terça-feira, 7 de julho de 2009

Affinity mask 0x0 ou 0xFFFFFFF?

Bom dia pessoal.

Durante o último treinamento de internals do SQL Server 2008 que ministrei, acabei pensando em um artigo interessante que pode mostrar como a falta de conhecimento do funcionamento do SQL Server pode impactar o seu ambiente. Hoje vamos falar do affinity mask.
Como vocês já sabem, o affinity mask define quais processadores o SQL Server vai utilizar, então se você possui oito processadores lógicos com o affinity mask definido para 85 (01010101 em binário), está indicando para o SQL Server utilizar o primeiro, terceiro, quinto e sétimo processadores. Por padrão o SQL Server configura o affinity mask como zero (“0”), o que indica que ele pode utilizar todos os processadores.
Com base nas afirmações acima, podemos tirar uma conclusão básica para minha máquina, que possui dois processadores (um slot dual-core): affinity mask = 0 é a mesma coisa que affinity mask 3 (11 em binário), pois ambos indicam que todos os processadores serão utilizados, certo?
Bem, infelizmente a afirmação acima não é totalmente verdadeira, o SQL Server vai utilizar os dois núcleos que tenho disponível, mas seu comportamento é diferente. Quer ver?

SQLOS basics

Sabemos que o SQL Server 2005 (e 2008) é NUMA aware (SQL Server 2000 com SP4 também? Hhhuuumm, bem +/-), o que significa que ele identifica os nós NUMA na sua máquina (hard ou soft) e associa um número X de schedulers a cada um dos nós. Sabendo que os schedulers não migram entre nós e os workers (threads ou fibers – aqui indiferente) estão vinculados a somente um scheduler, o SQLOS tenta balancear a carga entre schedulers através do load factor.
Mas e se, por acaso do destino, um scheduler receber alguns workers que estão executando tarefas mais pesadas e demoradas, haverá um desbalanceamento de uso da CPUs dentro do mesmo nó NUMA? A resposta é não, por padrão um scheduler poderá escolher qual CPU vai utilizar para colocar o worker para trabalhar, deixando aberto um grau de dinamismo entre CPU/scheduler, já que o worker está vinculado ao scheduler.
É claro que o SQL Server somente permite que CPUs do mesmo nó sejam utilizadas por um scheduler, evitando que o ganho pela localidade dos dados na memória do nó seja perdido com a alocação de uma CPU em um nó remoto. Quando falamos em paralelismo isso é factível de acontecer (novos workers em nós diferentes), mas aí com o particionamento dos dados pelo paralelismo você pode ganhar (ao invés de perder) usando as características de uma arquitetura NUMA.
O comportamento que citei acima somente pode acontecer quando o affinity mask está definido como zero. Isto é, se você especificar um affinity mask qualquer, mesmo que indique que todos os processadores serão utilizados, o SQLOS vai entender que um scheduler está vinculado a uma CPU, matando esse pequeno grau de dinamismo e somente confiando no load factor do scheduler.

Demonstração

Vamos a um exemplo simples. Minha máquina possui somente um nó (sys.dm_os_nodes) e dois schedulers (sys.dm_os_schedulers) que são utilizados para as requisições que chegam (deixe de lado hidden schedulers e o reservado para o DAC).
Com affinity mask = 0 eu começo a monitorar o contador “% processor time” (ou “% tempo do processador”) para os dois núcleos e vejo que minha máquina está trabalhando com uma média de 20% (cada um), mas quando eu abro uma nova conexão e executo o script abaixo (script 01) vejo que a média de utilização dos dois contadores sobe para uns 70%.

(Script 01)

DECLARE @I BIGINT = 0
DECLARE @S varchar(200)

WHILE @I < 100000000
BEGIN
select @S = @@VERSION
SET @I += 1
END

O que está acontecendo? A requisição (veja em sys.dm_exec_requests) recebeu um worker e está vinculada a um scheduler, mas esse por sua vez utiliza os dois processadores (em quantuns diferentes) para executar a tarefa, resultado em um uso equilibrado dos núcleos. O número resultante para o contador bate bem em cima do esperado, com um aumento de 50% para cada um.
Vamos mudar um pouco o cenário? Altero o affinity mask para três, indicando que o SQL Server também pode usar os dois núcleos disponíveis. Como resultado, temos a figura 01.

exec sp_configure 'affinity mask', 3
reconfigure


Veja que a diferença entre os dois momentos é clara (figura 01), em um primeiro momento a carga de 100% ficou dividida entre os núcleos, enquanto no segundo momento o SQL Server vinculou o scheduler a somente um núcleo, fazendo com que esse fique constantemente em 100% enquanto o outro fica com aproximadamente 20%.



(Figura 01)


Com isso eu demonstro meu ponto, affinity mask = 0 é diferente de affinity mask = 0xffffff (isto é, usando todos os núcleos), pois no segundo caso o SQL Server mantém uma afinidade entre scheduler e CPU.

O que isso significa para sua empresa? Talvez você não sinta um impacto direto dessa configuração, mas podemos supor um cenário potencial onde, mesmo o SQLOS usando o load factor dos schedulers para definir onde uma tarefa será executada, é factível termos tarefas pesadas caindo sobre um mesmo núcleo, demorando mais e usando de forma desigual os recursos de processamento disponíveis.
Se você quer que o SQL Server trabalhe com processadores específicos (affinity mask diferente de zero), mas não deseja que essa afinidade entre CPU/Scheduler seja respeitada, existe luz no fim do túnel, basta habilitar o trace flag 8002. De onde tirei isso? Leia a série inside SQL Server.

Gostou? Viu como um detalhe simples pode causar um eventual impacto, não reproduzível facilmente, no seu ambiente? Então entenda como o SQL Server funciona para não ser surpreendido...

Prefere ler o PDF deste artigo? Pegue no skydrive.







[]s
Luciano Caixeta Moreira - {Luti Nimbus}
Chief Innovation Officer
Sr. Nimbus Serviços em Tecnologia Ltda
E-mail: luciano.moreira@srnimbus.com.br

Um amigo se tornou MVP

Hoje recebi a ligação de um amigo de Brasília, que se tornou MVP (uma excelente notícia). Estou falando do Rogério Moraes de Carvalho.

Eu conheci o Rogério já faz alguns anos, enquanto ministrava treinamentos na Hepta Informática, e quando trabalhei na Microsoft eu trouxe ele para falar em alguns dos encontros que eu promovi em Brasília, além do TechEd 2008, onde chegamos a palestrar juntos.

Fico feliz pelo Rogério, pois é uma pessoa com um reconhecimento incrível aqui em Brasília e um cara com foco em excelência técnica ao invés de puro marketing pessoal. Espero que ele possa contribuir mais e mais com a comunidade, pois é necessário termos bom profissionais produzindo (e não somente reproduzindo) conteúdo de qualidade.

O anúncio saiu aqui: http://mvpbrasil.spaces.live.com/blog/cns!F5F4692D000CDE16!795.entry

[]s
Luciano Caixeta Moreira - {Luti}
Chief Innovation Officer
Sr. Nimbus Serviços em Tecnologia Ltda
E-mail: luciano.moreira@srnimbus.com.br

segunda-feira, 6 de julho de 2009

Segundo encontro do grupo SQLServerDF

Bom dia pessoal.
Depois de uma semana puxada com prova da Microsoft, prova no MBA e treinamento de internals e tuning do SQL Server 2008, nessa semana vamos fazer o segundo encontro do grupo SQLServerDF, PASS chapter do DF. Aqui está o programa...

Data: dia 09 de Julho de 2009, quinta-feira.
Hora: entre 19:00 e 22:00
Local: Auditório do CEFTRU (ao lado do CESPE) - UnB
Agenda:

- Plan cache, Stored Procedures, parametrização e compilação - (2hs) -
Luciano Caixeta Moreira (Luti)
- Pequeno intervalo
- Detabe técnico.

Descrição da sessão: O objetivo da apresentação é detalhar como funciona a cache de planos do SQL Server e o que acontece com sua consulta SQL ou procedimento, quando executada pela aplicação. Quais são as diferenças entre eles, o que é parametrização adhoc e parameter sniffing, quando uma consulta é (re)compilada e quais são os benefícios e eventuais problemas que a sua aplicação pode enfrentar.
Durante a sessão quebraremos alguns mitos, mostraremos que é importante sim o desenvolvedor conhecer um pouco (ou muito!) do SQL Server e esperamos preparar o pessoal para futuras discussões, como por exemplo, se vale a pena utilizarmos recursos do BD ou trabalharmos com uma tecnologia de mapeamento O/R.

Animou? Mande um e-mail para luciano.moreira@srnimbus.com.br.
Essa sessão é uma versão mais extensa (com mais demos e conteúdo) de uma apresentação que eu fiz no passado para o MSDN, e sinceramente, acho que vale cada minuto.

Se você não é de Brasília, mas quer participar das discussões do grupo e colaborar com o SQLServerDF, pode se juntar a nós através do grupo: http://groups.google.com/group/sqlserverdf, criado por outro membro do time que coordena o SQLServerDF, com o intuito de melhorarmos nossa comunicação.

Para quem não sabe chegar ao CEFTRU, segue um mapa que o pessoal de lá me passou: http://maps.google.com.br/maps?f=d&source=s_d&saddr=Central+%40-15.793379,-47.882592&daddr=Unb&geocode=FR0DD_8doF4l_Q%3BFVRTD_8dN54l_Q&hl=pt-BR&mra=pr&sll=-15.772782,-47.867496&sspn=0.010531,0.01929&ie=UTF8&t=h&z=16

[]s
Luciano Caixeta Moreira - {Luti}
Chief Innovation Officer
Sr. Nimbus Serviços em Tecnologia Ltda
E-mail: luciano.moreira@srnimbus.com.br