Monthly archives "February"

7 Articles

Nova versão da apresentação SQL Server CPUing – Part I!

Um palestrante da área de TI disse uma vez que todas suas apresentações sempre seriam diferentes, inclusive aquelas com exatamente o mesmo tema. Ele sempre revisaria algo e sempre mudaria algo.

Você sempre tem algo para mudar, e eu sou mais um para confirmar a afirmação acima. Recentemente eu apresentei uma palestra sobre CPU e SQL Server. Revisei o material e mudei algumas coisas. Na verdade, mudei muita coisa. Retirei todo o texto e mantive mais animações e diagramas. O Powerpoint é um ferramenta incrível.

Meu novo modelo de apresentação é baseado em animações em sua maioria, mantendo pouquíssimo texto, e um uso abusivo das anotações. Em breve irei refazer essa apresentação em alguns lugares e ela vai ser o projeto piloto para uma apresentação onde dominar o conteúdo e ter uma boa memória vão ser meus aliados, ao mesmo tempo que serei mais didático para quem vê. Assim espero!

O vídeo abaixo contém uma pequena demonstração do que estou preparando. Daqui alguns dias, irei postar o resultado, além de iniciar esta apresentação como um série, aqui no blog. Este post fala um pouco mais sobre a palestra e contém os arquivos antigos.

 

Desmistificando o SELECT no SQL Server: O FROM – 2ª Sub-fase

O FROM é a parte de um comando SELECT onde especificamos as tabelas que precisamos para extrair a informação. Assim como podemos efetuar algumas operações com números, é possível efetuar operações entre tabelas. Já vimos uma delas, o CROSS JOIN, que é uma operação para combinar cada linha de uma tabela com cada linha de outra tabela.

O CROSS JOIN é uma operação útil em muitos casos. Porém, creio que a operação mais usada é o famoso “INNER JOIN”. Acredito que a maioria daqueles que estão lendo este post aprenderam que o INNER JOIN serve para “juntar duas tabelas onde duas colunas possuem o mesmo valor”. Essa é uma definição boa e didática, mas a partir de agora esqueça a forma como você conhece um INNER JOIN. A 2ª Sub-fase do processamento lógico do JOIN, que faz parte do processamento lógico do FROM, irá te apresentar um nova forma de ver um INNER JOIN, e vai te permitir ter mais domínio e mais possibilidades de uso do mesmo.

A cláusula ON

Diferentemente do CROSS JOIN, todos os outros operadores de JOIN exigem que uma cláusula seja especificada: o “ON”. Esta cláusula permite que um filtro seja informado (na verdade, um predicado, ja já explico melhor). Este filtro pode ser qualquer expressão válida da linguagem T-SQL que resulte em VERDADEIRO ou FALSO. Isto é, você irá ver que um JOIN não significa juntar linhas onde uma coluna seja igual a outra, e sim, onde o predicado da cláusula ON seja VERDADEIRO!

A 2ª Sub-Fase: Aplicar o filtro da cláusula ON

No post anterior, você viu que o resultado da 1ª sub-fase é uma tabela contendo a combinação de todas linhas entre as duas tabelas envolvidas no operador que está sendo processado. Nós chamamos esse resultado de “VFROM-S1”, que é a tabela resultante da 1ª sub-fase.

Na próxima fase, o SQL Server vai pegar a “VFROM-S1” e adicionar uma nova coluna, que vamos chamar de “ResultadoON”, cujo os valores possíveis são  “VERDADEIRO” ou “FALSO”. Para cada linha de “VFROM-S1”, o SQL Server vai aplicar o filtro da cláusula ON e o resultado será salvo nesta nova coluna. Após avaliar todas as linhas, o SQL Server vai retornar somente as linhas cujo a coluna “ResutaldoON” seja VERDADEIRO. Este será o resultado produzido por esta fase.

Para cada linha da tabela VFROM-S1, o resultado do predicado ON será salvo na coluna ResultadoON. Somente as linhas onde esta coluna for VERDADEIRO serão mantidas

Para cada linha da tabela VFROM-S1, o resultado do predicado ON será salvo na coluna ResultadoON. Somente as linhas onde esta coluna for VERDADEIRO serão mantidas

E é isso o que faz um INNER JOIN. Ele mantém as linhas somente onde a condição do ON é VERDADEIRA. Geralmente, a condição que usamos é “Tabela_Esquerda.Coluna = Tabela_Direita.Coluna”. Mas nada impede que condições mais complexas sejam usadas, usando operadores de comparação mai complexos como um IN, EXISTS, etc.

Para ilustrar melhor o que ocorre nesta fase, vamos realizar um INNER JOIN simples, entre a tabela cliente e pedidos (scripts para criação lá no primeiro post). Vamos trazer todos os clientes e seus respectivos pedidos, segue:

Agora que conhecemos as duas primeiras sub-fases, podemos acompanhar, passo-a-passo como a query acima será processada. Vamos nos preocupar agora somente com o FROM.

Vamos acompanhar sub-fase por sub-fase o que ocorre em uma operação de JOIN simples

Vamos acompanhar sub-fase por sub-fase o que ocorre em uma operação de JOIN simples

Ao executar o FROM nos deparamos com o primeiro operador, um “INNER JOIN”. Sabemos que o “INNER JOIN” faz parte do grupo dos JOINS, então vamos executar as sub-fases do JOIN. A primeira sub-fase, conforme visto neste post, é o produto cartesiano entre as duas tabelas envolvidas. O resultado da primeira sub-fase seria este:

Conforme já mencionei, a primeira fase sempre é executada independentemente do tipo de JOIN

Conforme já mencionei, a primeira fase sempre é executada independentemente do tipo de JOIN

Bom, como a operação atual é um “INNER JOIN” então devemos passar para a próxima fase. Se fosse um “CROSS JOIN” iríamos parar exatamente aqui e esse seria o resultado do seu SELECT. Lembrando que se houverem mais operadores no FROM, este resultado seria o input da esquerda para o próximo operador!

Como estamos processando um INNER JOIN, agora o próximo passo é aplicar o filtro da cláusula ON. Primeiro, de posse da tabela virtual gerada pela 1ª sub-fase, a “VFROM-S1”, devemos adicionar a coluna “ResultadoON”. Para cada linha, o sql server vai avaliar a expressão na cláusula ON e o resultado será salvo nesta coluna, que será VERDADEIRO ou FALSO. A cláusula ON que foi informada na query é “C.clienteID = P.clienteID”. A tabela virtual “VFROM-S1”, iria se parecer com essa:

Na 2ª sub-fase do JOIN, para cada linha da tabela virtual VFROM-S1, vamos AVALIAR a condição da cláusula ON.

Repare nas duas linhas indicadas na imagem. A condição do filtro ON só enxerga os valores das colunas da linha em que está se verificando. Graças a isso, você consegue o efeito “somente linhas onde certas colunas são iguais”.

 

Neste ponto, o SQL Server vai manter somente as linhas onde a coluna “ResultadoON” seja “VERDADEIRO”.

Neste ponto, a coluna "ResultadoON" já possui os valores todos preenchidos. Devemos descartar todas as linhas que forem "FALSO".

Neste ponto, a coluna “ResultadoON” já possui os valores todos preenchidos. Devemos descartar todas as linhas que forem “FALSO”.

 

Em outras palavras, ele irá descatas as linhas onde “ResultadoON = FALSO”.

O resultado da 2ª sub-fase não inclui a coluna "ResultadoON", que é enxergada somente nesta fase.

O resultado da 2ª sub-fase não inclui a coluna “ResultadoON”, que é enxergada somente nesta fase.

 

Ao executar este código, você verá que o resultado produzido foi bem semelhante com essa tabela “VFROM-S2. Se houvesse mais JOINS no FROM, esse resultado iria servir como a tabela da esquerda para o próximo operador. Como em nossa query não há mais para processar no FROM, então este é o resultado do FROM. Fácil né!? Antes de finalizar, algumas observações:

  • Pode parecer absurdo essa lógica em tabelas muito grandes. Com certeza seria um processamento extremamente ineficiente. Porém, conforme eu já mencionei nos posts anteriores, o processamento físico, isto é, o caminho real a ser seguido pelo SQL Server, sofrerá algumas otimizações, mas o resultado produzido  será o mesmo que produzido seguindo o processamento lógico, exatamente o mesmo! Lembre-se: o processamento lógico é como o SQL Server entende o que deve ser feito.
  • A cláusula ON aceita qualquer EXPRESSÃO BOOLEANA VÁLIDA DO T-SQL. Para ser mais correto, o filtro ON pode ser qualquer “PREDICADO” válido. Um predicado é uma expressão que só tem dois resultados: VERDADEIRO ou FALSO (na verdade há um terceiro valor… mas isso é pra depois… :-)). Há vários operadores na linguagem T-SQL para construir desde predicados simples, até o mais complexos. No SQL Server existem somente três lugares em que podemos especificar predicados para filtrar linhas: Na cláusula ON, no WHERE e no HAVING. Isso significa, que todas estas queries são válidas e irão ser executadas sem erros para o SQL Server:

 NOTA: Não vá sair alterando todos as suas queries achando que vai melhorar a performance. Eu disse que todas as queries acima são válidas, não necessariamente são eficientes 🙂 . Por enquanto, estamos falando de processamento lógico, e precisamos primeiro entender o que os operadores fazem e o que eles irão produzir para depois otimizá-los. 

Agora você já sabe que o INNER JOIN não serve apenas para juntar linhas baseada na igualdade entre duas colunas. Usando a sua criatividade e juízo, você poderá começar a enxergar mais utilidades e aplicações do CROSS JOIN e INNER JOIN. O próximo post será sobre a 3ª sub-fase do JOIN e creio que muita coisas sobre LEFT JOINS e RIGHT JOINS serão desmitificadas e você irá dominar esses operadores.

Ah, apenas para reforçar, deixo claro que esta série é baseada no conteúdo do livro Inside SQL Server 2008: T-SQL Querying. Recomendo muuuuuuuuuuuuuuuuuuuuuuuuuuuito a leitura!

DESAFIO

Bom, será que você já desmistificou o INNER JOIN mesmo? Ou ainda treme igual uma mocinha indefesa só de pensar em usá-lo? Vejamos… Considere esta query que acabamos de usar:

Você já sabe o que ela faz: combina (junta, relaciona, gruda, como preferir) as linhas de Cliente e Pedido onde as colunas clienteID de Cliente e clienteID de Pedido possuem o mesmo valor. Inverta o filtro de igualdade para o filtro de desigualdade (“!=”):

E você irá fazer o contrário: trazer todos os pedidos que não pertencem aos clientes. Ora, o pedido de ID = 7 não pertence a nenhum cliente (cliente = NULL) e não foi retornado para nenhuma linha da tabela Cliente. NULL é diferente de qualquer coisa, certo? Realize um CROSS JOIN entre estas duas tabelas e você verá que o pedido de ID = 7 irá aparecer para cada cliente. Perguntas:

  • As linhas de Pedido, onde pedidoID = 7, foram removidas na primeira ou segunda fase do JOIN? Qual foi o motivo de terem sido removidas do resultado?
  • Se NULL é diferente de qualquer coisa, porque essa linha não foi retornada para cada cliente?

Os scripts para a criação das tabelas acima estão neste post. Utilize os comentários para deixar sua reposta! Até a próxima!

Desmistificando o SELECT no SQL Server: O FROM – 1ª Sub-Fase

Há muito tempo eu comecei uma série chamada “Desmistificando o SELECT no SQL Server”. Você pode acompanhar os links na lateral desta página para ler os posts antigos. Eu acrescentei mais imagens e alterei um pouco o conteúdo para tentar ser mais claro. Fique à vontade!

No último post, eu mencionei que o FROM é dividido em sub-fases, que variam conforme o operador que está sendo executado. Para cada operador usado, uma série de sub-fases serão executadas. Por agora vamos falar somente das sub-fases dos operadores de JOIN (CROSS JOIN, INNER JOIN, LEFT JOIN, RIGHT JOIN e FULL JOIN).

Lembre-se que cada operador de JOIN sempre vai executar no mínimo a primeira sub-fase. Alguns irão executar todas, outros somente até a segunda. Mas sempre vão iniciar na primeira e ir avançando sub-fase por sub-fase. Também, para cada sub-fase, uma tabela virtual é gerada e servirá como entrada para a próxima sub-fase.

Cada sub-fase do FROM gera uma tabela virtual que é passada para a próxima sub-fase. A última sub-fase gera a tabela virtual do FROM.

Cada sub-fase do FROM gera uma tabela virtual que é passada para a próxima sub-fase. A última sub-fase gera a tabela virtual do FROM.

 

Caso necessite de mais informações sobre tabelas virtuais dê uma olhada no post sobre processamento lógico e físico desta série.

1ª SUB-FASE: Produto Cartesiano

Nesta fase, é feito um produto Cartesiano entre os inputs. Para quem não lembra o produto cartesiano vem lá da teoria de conjuntos. Ele é uma operação onde todos os elementos de um conjunto são combinados com todos os elementos de um outro conjunto. Isto gera um conjunto com TODAS AS COMBINAÇÕES POSSÍVEIS.

Trazendo para esse contexto, os elementos que iremos combinar são as linhas das duas tabelas. Nesta sub-fase será gerado uma tabela virtual contendo todas as combinações possíveis de linhas entre os dois inputs. Se o input da esquerda contém 5 linhas  e o input da direita contém 2 linhas, a tabela virtual gerada aqui vai conter 5 x 2 = 10 linhas. Cada linha da esquerda será associada com cada linha da direita, isto inclui, todas as suas colunas.

 Considere duas tabelas. Um produto cartesiano entre essas duas tabelas, combina cada linha da tabela da esquerda com cada linha da tabela da direita

Considere duas tabelas. Um produto cartesiano entre essas duas tabelas, combina cada linha da tabela da esquerda com cada linha da tabela da direita

Na imagem acima, cada linha da tabela “Naipes” foi combinada com cada linha da tabela “Cartas”.  O resultado foi uma tabela com todas as linhas e colunas das duas tabelas combinadas, lado a lado. Se o operador fosse um CROSS JOIN esta tabela seria passada para a próxima fase, o WHERE. Se fosse um INNER JOIN, por exemplo, esta tabela seria repassada para próxima sub-fase, onde a cláusula ON seria avaliada para cada linha. Veremos mais no próximo post.

Para simplificar, vamos dizer que nesta fase é retornada uma tabela virtual chamada “VFROM-1”.

RELEMBRANDO JOINS

Joins são operações que usamos para combinar linhas de dois inputs (duas tabelas). O resultado de uma operação de JOIN é uma tabela que contém as colunas dos dois inputs. Dependendo do JOIN, você pode especificar uma condição, isto é, uma lógica, para determinar as combinações de linhas que vão ser geradas. Os tipos de JOINS suportadores pelo SQL Servers são:

CROSS JOIN
INNER JOIN
LEFT JOIN
RIGHT JOIN
FULL JOIN

Este link, do BOOKS ONLINE contém mais informações.

Bom, por enquanto é só. No próximo post irei falar sobre as outras fases.  Até lá, vá revendo os tipos de JOINS. Para este momento entender e vê exemplos de JOINs irão facilitar ainda mais sua compreensão.

E como sempre, desculpem os erros de português. A cada post estou tentando melhorar e ser mais claro. Qualquer dúvida, sugestão, crítica, ou elogios, utilize os comentários! Seu feedback sempre é bem vindo!

SQL Server e Atualizações

Olá!

Você mantém seu ambiente atualizado?

Se não, você pode estar  sujeito à problemas já corrigidos pela Microsoft. As atualizações devem ser planejadas pois podem parar seu ambiente por um bom tempo, durante o período de instalação da mesma (em breve um post sobre isso e um caso real).

Eu gosto de acompanhar as atualizações pelo site SQL Server BUILDS. Lá você encontra um link para todas as atualizações lançadas de todas as versões da Microsoft. O site não é oficial, mas os links disponibilizados são os oficiais.

Você também pode conferir quais bugs uma determinada atualização irá corrigir, entre outras informações no link do KB associado à atualização.

Acesse o link e lembre-se, planeje a atualização conforme as necessidades do seu ambiente!

O que é powershell?

Lembra do cmd.exe? Prompt de comando, telinha preta, etc. São vários os nomes dados ao Shell padrão do Windows.

cmd.exe

 

Isto também é um shell

Isto também é um shell

Acredito que a primeira dificuldade em entender o que é o powershell é entender antes o que é um Shell. Bom… Um shell é uma interface em que o usuário do sistema operacional pode interagir com os serviços oferecidos por ele (Fonte: Wikipédia).  Ou seja, você fornece comandos para o shell, e o shell transforma o que você forneceu em chamadas para as funções internas do sistema operacional, que vai te dar uma resposta ou fazer alguma operação, baseado neste comando. Em poucas palavras e grosseiramente falando, é apenas um programa que recebe comandos e chama as funções correspondentes da API do sistema operacional, recebe o resultado e transforma em algo mais legível para você, reles humano.

Um shell

O cmd.exe  era o shell padrão. Ele era baseado na mesma interface do antepassado do Windows: o DOS (daí porque é chamado de DOS também). Além de permitir usar elementos comuns de linguagens de programação, como loops, variáveis, você podia usar comandos para listar diretórios, obter informações de disco, formatá-los, etc.

O powershell é a evolução do cmd.  Na minha opinião, uma das grandes vantagens do powershell é que ele usa todo o .NET como sua base. Você praticamente pode programar em C# na linha de comando. Isso te permite construir scripts avançados, que fazem tarefas complexas, com apenas algumas linhas de código, sem precisar abrir um Visual Studio e compilar algo. Outra grande vantagem é o fato de que os resultados dos comandos são retornados como objetos, e não como texto. Isso permite que você manipule mais facilmente o retorno dos comandos, ainda mais quando você precisa passar resultados de um comando para outro comando. (O famoso pipe “|”). Também, o powershell te permite interagir facilmente com o WMI (um serviço do Windows que provê uma série de informações sobre o Hardware e Software), facilita o processo de execução de scripts em máquinas distintas, e uma série de outros recursos.

A interface padrão do powershell. Telinha preta, nunca mais! Será mesmo!?

A interface padrão do powershell. Telinha preta, nunca mais! Será mesmo!?

Em breve, mais postagens sobre POWERSHELL!

Iniciando em powershell:

http://abstrys.com/doku.php/technology/powershell/beginning-powershell-scripting

http://www.powershellpro.com/powershell-tutorial-introduction/