Results for tag "microsoft"

7 Articles

Um Generalista a mais no mercado?

Depois de um longo tempo sem postagem no blog, estou voltando aqui com algumas novidades. O tempo tem sido crucial, e muitas mudanças aconteceram em minha carreira e vida pessoal. Com isso acabei me afastando do blog. O post hoje conta um pouco do que aconteceu e o que espero pro ano de 2019!

 

Novos conhecimentos, mesmos meios

Depois de longos anos trabalhando com plataforma Microsoft, exclusivamente SQL Server e Windows, finalmente encarei a chance de conhecer outros produtos. Não um específico, mas diversos: o problema aparecia, e tinha que resolver.  Mysql, PostgreSQL, Oracle, DB2, sqlite, etc. Em um primeiro momento, acostumar com essas novas tecnologias é difícil, e chega até ser desanimador.  O SQL Server realmente é um produto incrível, e possui muitas features que tornam o dia-a-dia de um DBA muito mais fácil, porém nada básico. Possui uma engine poderosa, capaz de suportar os mais severos workloads, oriundos das mais exigentes aplicações do planeta. Por um outro lado, existem muitas features interessantes, e que até faltam no SQL Server.

Junto com o receio de se tornar um generalista, resolvi encarar o desafio. O resultado dessa experiência, conto um pouco a seguir.

A maior mudança: Linux

Sem dúvida, o maior conhecimento adquirido foi o Linux. Apesar de passar a maior parte do tempo em uma tela preta, sem usar mouse, diferente do Windows, isso não me trouxe limitação. A princípio, parece que aquilo é realmente uma caixa preta e qualquer mensagem significa o caos. Besteira. Um ambiente robusto, cheio  de controles, lógica, configurações, desafios. Nada diferente do Windows. Apenas um jeito diferente.

Aprender a usar Linux foi um dos, senão o maior, conhecimento que adquiri depois de aprender a programar e SQL Server. Eu não escondo para os meus colegas que sou fascinado pelo “internals” do SO, e o Linux me apresentou centenas de oportunidades para aprofundar mais esse conhecimento. Há quem diga que Windows é melhor, ou que Linux é melhor, ou ainda que Debian é melhor que CentOs, e vice-versa (feliz por entender agora o que esses termos significam). A velha história das comparações… Seguramente, posso dizer que é uma tremenda perda de tempo cair nessa discussão.

Hoje sou um apaixonado por bash, e meu velho powershell. Estou mesmo satisfeito por conhecer mais Linux, e poder explorar o melhor dos dois mundos. Agora, não importa se o problema é um pinguim adoecido, ou uma janela quebrada. Estarei aqui com as melhores ferramentas para resolvê-los.

 

Uma nova gama de opções de configuração e conceitos

Tive o prazer de atuar em problemas diversos em outras tecnologias de banco. Do mais simples aos mais complexos. Um dos meus primeiros desafios nos PostgreSQL foi apenas liberar o acesso de um usuário a partir de um novo IP.  Há um arquivo de configuração que você precisa editar pra isso. Aliás, é uma abordagem interessante. Diferente do SQL, há recursos nativos em outros bancos, como o PostgreSQL e no MySQL,  em que você consegue limitar o acesso do usuário a partir de um endereço. Realmente necessário? Uma discursão interessante pra uma conversa numa mesa de bar! 😆

Acostumar-se como o SQL Server instala seus binários, me fez ficar confuso com algumas tecnologias. Porém, comparar o conceito de instância do SQL Server, com os outros SGBDs, tornou as coisas mais claras no Oracle e no DB2.  No Oracle, o procedimento de instalação, reconhecido na comunidade técnica por ser “difícil”,  vai ficando mais claro a medida que você entende os conceitos. Muita coisa são apenas padrões, que, repassando de geração em geração, se torna um “é assim que se faz, pronto e acabou”. Cheguei até o ponto de criar novas instâncias Oracle manualmente, e me admirei com o fato que com apenas copiando alguns arquivos, você sobe uma “monstruosa” nova instância…  Minha dica é: entenda os conceitos de instância em “Oracle” e DB2 e você sairá vitorioso no primeiro contato com essas plataformas!

Planos de execução e Otimização de Queries

Uma das maiores causadoras de problemas em produção, a famosa lentidão de queries, não é exclusivo do SQL Server. Há sempre uma demanda para “pega as queries mais lenta e otimiza”. Essa nova jornada me trouxe um valioso conhecimento: Aprender a ler planos de execução no PostgreSQL, MySQL, etc. Sem muitas opções gráficas, me acostumei com a leitura do plano em texto.  A complexidade do Query Optimizer (QO) do SQL server deixou o caminho mais fácil para entender compreender o MySQL, que apesar de mais simples, toma decisões eficientes e inteligentes, que poupa trabalhos dos desenvolvedores. Porém, me ajudou a entender muito mais rápido os operadores do PostgreSQL, que possui uma gama infinita, com muito mais opções para controlar as decisões de seu otimizador, entretanto, com muita coisa semelhante do QO do SQL.

Num outro cenário, precisei avaliar o porquê de um simples banco no MySQL, em um portal de internet de um importante orgão do país, estava lento. Pra quem vem do SQL, é meio complicado lidar com a falta de uma sys.dm_exec_requests, ou sp_WhoIsActive. Mas, o meio de encontrar o problema é o mesmo: descubra a query, ou as queries lentas, e quais são seus gargalos. Aliado com as ferramentas do SO, conseguimos entender o problema, onde estava a limitação, e resolvemos isso usando recursos do Linux!

Também, apareceu uma chance incrível de operar um DB2, identificar locks, criar usuários, resolver gargalos, e até gerenciar uma replicação de dados!

Manipulação de Dados

Apareceu um desafio de auxiliar um processo de Auditoria de uma importante rede internacional de supermercados. Era necessário exportar conteúdo de um banco Oracle. Não tínhamos SSIS, nem interface gráfica. O desafio era tudo via linha de comando, era o que podia. Utilizamos a versão sqlcmd do oracle, o sqlplus. Com uma gama de opções, conseguimos exportar o conteúdo com sucesso.  O reconhecimento do vice-presidente desta empresa,  fez todo o esforço de usar powershell, para gerar um script bash que executava o sqlplus, valer a pena!

A triste e velha história da recuperação

Infelizmente, apesar de tantas diferenças, um problema comum: Recuperação. “O banco deu pau e não tem backup”.  Há quem diga que saber internals dos produtos é uma perda de tempo. Talvez sim, para aqueles que possuem recursos para suprir esse tipo de problema, ou mesmo que conseguem se convencer que tudo acabou nessas situações.

Além de conhecer novas formas, ferramentas e tipos de backup/restore (e em agluns casos, apenas diferente sintaxe, para os mesmos comandos), conseguir trabalhar em casos de recuperação de bancos sem backup.  Costurando bits, analisando logs, etc. Igual sempre foi no SQL nessas situações.  Alguns produtos apresentam uma comunidade forte, e documentação boa, outros nem tanto. A comunidade SQL Server realmente é um destaque quando se trata de conhecimentos mais avançados. Mas, é sensacional o fato de você poder ollhar no código-fonte do produto, gastar algumas horinhas apenas fazendo pesquisa de funções C++, entendedo as lógicas, em meios a poucos comentários de código.

 

Novos times

Uma das maiores  novidades, e, que, com muito orgulho, anuncio, foi a de entrar para o time da Fabrício Lima Soluções em Bancos de Dados.  O meu foco é o trabalho com SQL e Azure. Um time que já é muito forte e realmente tem sido animador. Além dos casos que aparecem, temos grupos de estudo, colocamos as experiências de todos para gerar soluções ótimas. É incrível o que esses caras fazem, e não é exagero a hashtag #AlwaysTunningYourData, porque é pra isso que todo esse conhecimento serve: pra fazer com que o seu SQL Server voe, seguindo as melhores e mais eficientes práticas.

Uma oportunidade que, chegou em um momento em que eu estava me distanciando do operacional de banco de dados, na Stefanini. Tendendo para automações de ações e serviços da infraestrutura, exigência da própria Adminstração de Banco de Dados, cheguei em uma equipe de inovação. Aqui aprendi python, docker(e já entrando em kubernetes), serviços cognitivos, machine learning, etc. Uma incrível oportunidade em um momento que todo o mundo já se volta para essas tecnologias!

Realmente tenho muito orgulho dos times que faço parte hoje. Ambos se beneficam das experiências adquiridas em cada um, e me apoiam. Isso faz toda diferença e realmente estou muito empolgado para 2019!

 

Na realidade, nada novo…

Apesar dessas novidades,  a essência não mudou. Ainda continuo apaixonado por assuntos de tecnologia, e gasto horas tentando entender os porquês. Se aparece um problema, seja com python, seja com sql no linux, sql no docker, db2 em Windows, eu passo algumas horas analisando cada log, cada mensagem, juntando as peças, consultando informações, abrindo ferramentas de monitoramento e trace. Tudo está interligado. Cada conhecimento em uma tecnologia, cada forma de resolver o problema, preenche uma vasta biblioteca na minha cabeça (e no meu OneNote,  Dropbox, etc.) com tudo que preciso para resolver os problemas.

E é nisso que se tem se resumindo meu dia-a-dia. Continuo sim, atuando em bancos de dados, especialmente na infraestrutura, resolvendo diretamente casos críticos ou discutindo com uma equipe como resolver. Continuo abrindo o Process Explorer, mas agora abro htop, ps ou top também. Ainda, nos casos mais bizarros, abro o Process Monitor, mas também abro o strace agora. Mais do que nunca tenho brincando com o Windbg ( e ainda não abrir um debugger no Linux, mas estamos quase lá  :-D). Leio internals de Windows, e também já lí o incrível Kernel Development do Linux. E também frequentemente consulto o código-fonte para tirar algumas dúvidas (uma delas, foi auxiliar no entendimento do “Load Average”).

Espero trazer mais em 2019 (e nesse finalzinho de 2018 também)! Mostrar como usar ferramentas, explicar conceitos, etc. Tudo o que já vinha escrito neste blog, porém com mais gama de experiência, tecnologias e ferramentas! E então, será que eu me tornei mesmo um Generalista? Não! Ainda estou envolvido com tecnologias específicas! Mas, estou acompanhando a TI, e indo com as novidades, levando tudo que aprendi até hoje para esse mundo! E tem dado certo, muito certo!

Pra fechar, novamente, a imagem que abre esse post: reflete o que foi esses meus 9 anos na área de TI, retirado da minha palestra no SQL Saturday 811:

 

AFTER SQL SATURDAY 424

SQL Saturday #424

SQL Saturday #424

Sensacionalmente fantástico. É assim que começo este post para tentar descrever o que foi o evento que aconteceu em uma das maiores cidades do mundo. No último sábado, dia 26/09/2015, aconteceu o SQL Saturday 424 em São Paulo.  O evento estava lotado e contou com a presença de grandes nomes da comunidade SQL e Microsoft.

O Evento

O show não foi somente por conta dos palestrantes, que aliás tinham muitos e que muita gente conhece através dos artigos que compartilham no mundo virtual. Uma das coisas que mais me impressionou foi o nível técnico daqueles que prestigiavam o evento. Os palestrantes puderam explorar ao máximo, oferecendo um conteúdo de qualidade, compartilhando informações que você não encontra em qualquer literatura, além de arrancar boas risadas com as descontrações.

A importância do evento não se limita somente às apresentações, mas ao networking. Conheci e conversei com muita gente, que conhecia apenas por e-mail, ou por ler algum artigo, e talvez essa tenha sido, para mim, a experiência mais marcante do evento. (Na verdade, mais marcante para mim, foi a minha própria apresentação (que irei falar sobre já já), e o networking ficou em segundo lugar. 🙂 ).

Outro espetáculo foi a organização do evento, que, apesar de gratuito, ofereceu coffee breaks, kits, livros (muita gente saiu feliz com a versão impressa do Complete Showplan Operators, do Fabiano Amorim. Ganhei o meu e recomendo fortemente!) e sorteou brindes. Tudo isso deve-se ao apoio dos patrocinadores e faço questão de deixar o meu muito obrigado:

Patrocinadores SQLSaturday

Também, deixo aqui os meus parabéns ao organizador do evento, o Diego Nogare (@DiegoNogare), que fez com que este evento honrasse o nome que carrega. Parabéns Diego! Mandou bem!

Bom, se você quiser conferir as fotos do evento pode ir lá no Blog do Marcelo Fernandes (@marcelodba) que além de apresentar, cuidou de registrar todos os momentos!

 

 

A minha apresentação

SQL Server, Windows e CPU. Este foi o título da minha apresentação. Com a sala cheia, fiquei bem à vontade e consegui entregar o que queria dentro do tempo de 60 minutos. Foi muito gratificante poder ver que a turma estava bem atenta e tranquila. Ver as pessoas assistindo e compreendendo este assunto, que apesar de simples e com um nível 100, foi incrível, e valeu a pena todo o esforço que coloquei em cada slide ou script. A minha responsabilidade ficou maior, quando, um pouco depois do início, o MCM Fabrício Catae (@FCatae) veio assitir a apresentação. Foi incrível poder apresentar um assunto tão simples, para um público que tinha desde quem nunca mexeu com SQL até aqueles que são referência no Brasil e no mundo. A sensação foi de missão cumprida, e se você estiver lendo este post e particiou de minha apresentação, deixo aqui um imenso muuuuuuuuuuuuuuuuuuuuito obrigado pelo o pouqinho do seu tempo!

Como forma de agradecimento e compromisso, eu disponibilizo os slides de minha apresentação, juntamtente com todos os scripts de todas as demos. A versão em PDF contém anotações detalhadas em um pouco mais completas daquilo que falei na apresentação, além do passo a passo para reproduzir as demos. Você pode baixar usando as seguintes opções:

 

Bom, novamente, agradeço muito a organização do evento, os voluntários, os palestrantes, e todo o púbico que foi prestigiar.

Palestrantes SQL Saturday 424

Palestrantes SQL Saturday 424

 

 

E a história não acaba por aqui

Está vendo como é importante participar destes eventos? Você aprende coisas novas, conhece pessoas, fecha negócios e se diverte. Já se inscreveu para Brasília? O evento vai acontecer de novo, em novembro! É o SQL Saturday 469! Não perca esta oportunidade, clique na imagem e garanta sua vaga! É gratuito!

SQL Saturday 469 BrasíliaSQL Saturday 469

 

 

[]’s
Rodrigo Ribeiro Gomes

 

 

 

 

 

 

1. SQL Server, Datas e Horas

Post 1/3. Este post é parte da série: SQL Server: Esclarecendo Datas e Horas

Tempo é uma coisa interessante. Dias, anos, horas, minutos, milissegundos… Em algum momento de sua vida com banco de dados você precisou, ou vai precisar, trabalhar com tempo. Datas e horas nos permitem realizar métricas, organizar compromissos, etc., e a maioria dos sistemas hoje em dia necessitam manipular data e hora.

O SQL Server fornece um amplo suporte para que você possa não só armazenar, mas realizar diversas operações como somar, ou subtrair, horas, dias, segundos, anos, ordenar e comparar data e hora! Porém, existe uma série de mitos e confusões relacionados a este assunto. Por exemplo, você é capaz de explicar o porquê isso acontece?

Ao converter uma string para data, o SQL não apresentou o mesmo horário

Ao converter uma string para data, o SQL não apresentou o mesmo horário

O objetivo deste post é esclarecer como manipular datas dentro de seus scripts T-SQL.  Iremos abordar os seguintes assuntos:

  1. Representando datas
  2. Formatando a exibição
  3. Tipos de dados de data

Por hoje, vamos focar na representação das datas, isto é, o modo como o SQL Server entende as datas que enviamos para ele.

Formato de Datas

Vamos começar falando do formato. Existe uma enorme confusão neste assunto. Primeiro, vamos deixar uma coisa bem clara: existem as datas que sua aplicação envia para o SQL Server, via código T-SQL, e as datas que o SQL Server envia para a sua aplicação. São duas coisas diferentes.

Fornecendo Datas para o SQL Server

Quando você envia um código T-SQL para o SQL Server, quem na verdade envia é uma aplicação. A aplicação é o que chamamos de client (por conta da arquitetura client-server).  Tudo que um client faz é pegar um código T-SQL, que não passa de texto (string), entregar ao SQL Server para ele processar, e esperar a resposta. Quando o client precisa fornecer uma data ao SQL Server ela vai junto com o código TSQL, como texto puro também.

Esta data que vai no código é o que podemos chamar de “formato de entrada“. Especificar uma data no SQL Server é muito simples: basta colocar a bendita entre aspas simples (‘). Isso mesmo jovem, você especifica datas igual especifica uma string qualquer dentro da linguagem T-SQL. O SQL Server só vai entender que aquilo é uma data, e não uma string qualquer, se ela for convertida para um tipo de dados de data, como por exemplo datetimetimedatedatetime2, etc. Essa conversão pode ser explícita ou implícita:

  • Implícitas
    • Quando atribui para uma variável do tipo data
    • Quando atribui para uma coluna do tipo data
    • Quando compara com alguma expressão do tipo data
  • Explícitas
    • Quando converte usando CAST ou CONVERT para um tipo de data
       

Apesar do SQL Server parecer bem flexível quanto ao formato de entrada, você não pode colocar qualquer coisa. Não é a casa da mãe Joana não! Ao converter sua string para uma data, o SQL Server vai validar o formato e se não estiver em conformidade você irá receber um erro dizendo que não foi possível converter uma data a partir de uma string.

SQL Server Error 241

Este é o erro que você irá ver com mais frequência quando estiver trabalhando com datas e o formato estiver errado.

Essa string que contém uma data, que você coloca no código SQL, é chamada de Literal (ou constante) de data e pode ser interpretado de várias formas.  Aqui na documentação você tem todos os detalhes. O formato mais comum de um literal de data no SQL Server é:

Formato Geral de Literal de Datas

 

A primeira coisa é entender os separadores. Basicamente, uma data é composta de várias partes: dia, mês, ano, hora, minutos, segundos e milissegundos. O SQL Server suporta barra (/), o ponto (.) e o traço como separadores para a parte dos dias. Para a parte das horas somente os dois-pontos (:) podem ser usados para separar horas, minutos e segundos. E somente o ponto pode ser usado para separar milissegundos. Todas as datas a seguir são válidas:

Se você especificar um separador diferente destes mencionados acima,  vai dar erro…

Msg 241, Level 16, State 1, Line 1
Conversion failed when converting date and/or time from character string.
Msg 242, Level 16, State 3, Line 1
The conversion of a varchar data type to a datetime data type resulted in an out-of-range value.

Você pode omitir certas partes da data. Quando faz isso, o SQL Server considera a parte omitida como 0 (zero).  Se omitir a parte das horas, isto é, especificar somente dia, mês e ano, o horário será o mesmo que 00:00:00.000, isto é, meia noite em ponto! O horário tem de ser especificado no formato “HH:mm:SS.Milissegundos [AM|PM]“. Veja alguns exemplos:

O tipo “datetime” permite que você especifique até 3 casas nos milissegundos. Os tipos time e datetime2 permitem até 7 casas! Depois falamos mais sobre os diferentes tipos de dados de data e hora. Por agora, concentre-se no formato. Outra  coisa interessante é que você pode especificar o formato 12 horas (AM/PM) nas horas!

O SQL Server não é idiota, portanto não tente um 13 da manhã…

Curiosamente, isso é inválido e gera erro (omitir toda a parte do horário, exceto as horas):

Porém, se você especifica AM ou PM…

Usar separadores de datas força o SQL Server a levar em consideração a região. Isto é, quando você usa um separador na parte dos dias, o SQL Server irá levar em consideração, por exemplo, o formato Brasil (dd/MM/AAAA) ou EUA (MM/dd/AAAA). A data abaixo pode ser 02 de fevereiro ou 01 de janeiro, dependendo de como o SQL Server está interpretando:

SET DATEFORMAT não é pra exibição!E é aqui onde entra o comando SET DATEFORMAT. Este comando é muito polêmico. A maioria dos desenvolvedores acha que ele irá alterar a forma como a data é exibida. Pegadinha! Este comando apenas diz para o SQL Server como ele deve considerar o formato das datas de ENTRADA. Ele é a maneira de você dizer “SQL Server, estou te enviando as datas neste formato“.   Para saber qual o valor atual do dateformat, você pode executar este SELECT:

O DATEFORMAT diz ao SQL Server onde está o dia, o mês, e o ano em sua data. Cada sessão possui seu dateformat, e não afeta o dateformat de outras sessões.

O DATEFORMAT padrão é definido quando você se conecta e é baseado nas configurações de idioma do login que você usa pra se conectar. Nós podemos alterar o DATEFORMAT a qualquer momento:

Lembre-se que o SET DATEFORMAT só irá afetar aquela sessão em que está se executando o comando. Quando você se desconectar (ou sua aplicação) do SQL Server, ou mesmo abrir outra sessão, o dateformat será baseado nas configurações do Login usado para a conexão.

Este aqui irá gerar erro, pois, conforme o dateformat configurado, não existe um 01 do 13…

Se você alterar o dateformat, deverá alterar o formato de suas datas:

No caso do ano, se você especificar o ano com 4 dígitos, o SQL Server detecta onde o ano está. Neste caso o dateformat vai valer somente para a posição do dia e do mês:

Sim, isso é um saco! Felizmente você pode contornar isso apenas deixando de usar os separadores. Sim, meu caro, quando não se usa separadores o SQL Server interpreta a sua data usando o formato ISO 8601 que é um formato padrão, independente do buraco do mundo onde você esteja!  Este formato sempre irá considerar AnoMêsDia ou AAAA/MM/DD ou AA/MM/DD. Sempre! Sempre! Independente do DATEFORMAT!

E você pode continuar especificando as horas normalmente, já que é sempre o mesmo formato, independente da região:

Eu gosto muito deste formato e sempre estou usando nos meus scripts. Mas você deve tomar muito cuidado pra não cometer alguns errinhos:

Fique atento ao tipos de dados também…

 

Bom, para deixar você respirar um pouco, vou encerrar por aqui. Na próxima semana posto a continuação! Fique ligado no blog!

 

[]’s

 

 

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

Post 5/5. Este post é parte da série: Desmitificando o SELECT no SQL Server

sql=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!

SQL Saturday #253

Galera, é com muita felicidade e empolgação que anuncio o primeiro SQL Saturday de Brasília, e também minha primeira oportunidade como palestrante.

O evento

O SQL Saturday é um evento gratuito, que acontece no mundo todo, voltado para SQL Server e acontece, na maioria dos casos, em um sábado. É o dia inteiro com palestras sobre temas voltados ao produto. Aqui em Brasília será o de número #253.

Já temos mais de 400 inscritos no evento da capital brasileira, e isso reforça que além de ser uma boa oportunidade para aprender e tirar dúvidas sobre SQL, você poderá conhecer novos profissionais da área e fazer networking.

O evento vai ocorrer lá em Taguatinga, na Faculdade Projeção. Mais informações, consulte o link abaixo.

Também, para as empresas da área de TI, é um excelente local para encontrar aquele profissional que estão precisando. As empresas que quiserem patrocinar o evento, podem entrar em contato com o organizador do evento aqui em Brasília, Luciano Moreira [luti], no seguinte endereço: luciano.moreira@srnimbus.com.br.

Aqui em brasília, teremos temos bem legais divididos em 4 categorias (tracks): Desenvolvimento (Dev), DBA, BI (Business Intelligence) e Academic (Iniciante). A agenda do evento é a seguinte: (ainda poderá sofrer algumas pequenas alterações)

SQLSat253_Agenda

Então como podem ver são temos bastantes interessantes, então nao fique de fora!

Para participar você apenas precisa se registrar no link: http://www.sqlsaturday.com/253/register.aspx (apenas em inglês)

Você também pode encontrar mais informações em: http://www.sqlsaturday.com/253/eventhome.aspx

Minha palestra

Como eu disse agorinha, eu terei a primeira oportunidade de palestrar em um evento oficial. Estou muito empolgado e feliz, pois  sempre aprendi lendo posts, livros, videos de pessoas que tiveram a boa vontade de passar o conhecimento, e poder retribuir isso é gratificante!!!

Irei falar sobre um tema que já tive muitas dúvidas, inclusive desde quando era um desenvolvedor SQL: Índices. Quando escrevia códigos, sempre queria saber como otimizar as consultas e muitas respostas me levaram a artigos e sites falando sobre “índices”. Me lembro que uma das perguntas que eu me fazia era: “Se um índice ajuda tanto, porque ele já não vem criado?”.  Também, já vi muitos desenvolvedores chegarem a pedir a criação dos mesmos com justificativas nada convincentes. E ainda, onde eu mesmo já fui vítima, já vi pessoas sugerir a criação de um índice na intenção de melhorar uma consulta, e na verdade o mesmo não iria ajudar em nada.

Com base nisso, o objetivo desta palestra, Índices: Introdução, é responder algumas perguntas comuns a quem nunca teve contato, ou teve pouco com eles:

  • O que são índices e como eles podem ajudar a melhorar uma consulta ?
  • Quando um índice ajuda ?
  • Quando um índice não ajuda ?
  • Por que os índices já não vem criados se eles ajudam tanto ?

E para  entendermos isso eu estou partindo do principio que o publico alvo da palestra seja realmente aqueles que desenvolvem usando o T-SQL ou que já tiveram um contato bem superficial com índices.

Assim, a palestra terá uma base para entendermos um pouco como as coisas são armazenadas dentro do SQL Server, e a partir daí iremos caminhando entendendo alguns problemas que existem, e finalmente como os índices podem ajudar. Aí então, vamos aprender como o SQL Server implementa isso, e como usamos esse recurso bastante poderoso (sim, consultas de 1 min podem cair para segundos com isso).

Segue o tópicos que pretendo abordar:

    1. Overview de Tabelas e Colunas
    2. Overview de Tipos de Dados
    3. Como os dados de tabelas são armazenados?
      1. Data Pages
    4. Pesquisando valores em tabelas
    5. O conceito de Índices
    6. Tipos de Índices no SQL Server
    7. Características e Utilização
    8. Os custos de se ter Índices

É claro que daqui para o dia do evento poderei acrescentar, ou mesmo tirar, alguns tópicos, mas a ideia gira em torno disso aí.

Após isso, espero que os presentes consigam entender melhor para que serve um índice e quando ele pode ajudar ou não.

Bom caro amigo, então é isso! Espero que goste do evento, e que aproveite a oportunidade. Depois do evento posto no blog como foi e os arquivos da palestra! Espero você lá!

 

Rodrigo Ribeiro Gomes
[]’s