THE SQL TIMES

Respondendo os porquês sobre SQL Server, Windows, programação e outros assuntos sobre tecnologia

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

Relâmpago: Como usar sp_helptext

Essa procedure permite você trazer informações das definições (codigo-fonte) de vários módulos, como triggers, procedures , views, funções, etc.

A sintaxe é:

EXEC sp_helptext ‘schema.NomeObjeto’

O objeto deve estar no mesmo banco onde se está executando o comando acima. Lembre-se que se a definição do objeto estiver criptografado, você não conseguirá ver. Por padrão, a procedure vai exibir no máximo 255 caracteres por linha. (Caso tenha uma linha com mais que isso, podem ocorrer problemas na execução pois ela vai quebrar a continuação da linha).

DICAS:

  • Você pode configurar query shortcuts (veja meu post sobre isso) para facilitar o uso. Em suma, você pode atribuir um atalho a chamada da procedure.
  • Se você optar por exibir no modo “Grid” a formatação do GRID acaba danificando a formatação original..Uma boa técnica é escolher exibir o resultado em texto. Atalho para isso é “CTRL + T”.

Rodrigo Ribeiro Gomes
[]’s

Novidade no Blog: Posts Relâmpagos

relampagoV

Apresento a vocês, o espaço “Relâmpago!”. O objetivo deste espaço é colocar post breves com informações e dicas em resposta aos termos pesquisados pelas pessoas. Por exemplo, se eu ver que você chegou ao blog através do termo “como usar o sp_helptext” eu irei tentar escrever um post breve sobre isso, e é claro fornecer informações úteis! A idéia é não ter um post longo, mas que tente sanar boa parte da sua dúvida e ainda te fornecer mais algumas detalhes e outros direcionamentos. É claro que estes termos podem gerar posts mais longos, então se for o caso poderei colocar na fila de posts. Também, nem de origem de pesquisas, mas até de conversas simples com colegas, situações do dia-a-dia, etc. Espero que gostem da idéia e que seja útil a nossa rede!

Para facilitar eles serão categorizados com o nome “relampago”, assim fica fácil procurar algo. Também irei sempre começar o nome com “Relâmpago: ”.

Impressões da Prova 70-457: SQL 2008–> 2012 (Part 1)

Bom hoje eu resolvi quebrar um pouco da série, e dar um feedback sobre a prova 70-457 (Transition your MCTS on SQL Server 2008 to MCSA: SQL Server 2012, Part 1). Como minha primeira prova de transição eu fiquei um pouco surpreso com o formato. A prova é tem 50 questões, dividas em duas partes de 25.

Na primeira parte, veio muita questão voltada a administração. Num primeiro momento, como eu não sabia, achava queria cair mais algo voltado para desenvolvimento. Questões bastantes conhecidas para quem fez as provas do 2005/2008 estavam lá. Uma que me lembro, e que é comum entre as atividades da maioria dos DBA’s, era sobre o logs do SQL Agent: Você precisava ver o output produzido pelas steps de um job a questão te perguntava como habilitar isso.  Backup & Restore tomou conta em umas 3 ou 4 questões. Uma delas te perguntava quais os passos para restaurar um backup do SQL Server 2005 para o 2012. Falando em passos, uma coisa na prova deixou ela mais fácil: as perguntas cujo a resposta era composta por várias ações sempre tinham o número de passos. Isso facilita um pouco quem não domina determinado assunto, mas tem alguma noção. Por exemplo, a pergunta final do backup acima era mais ou menos assim:

“Quais os três passos para se completar a tarefa”

Em relação a alta disponibilidade caiu boas perguntas sobre as tecnologias novas e as velhas conhecidas, como replicação. Nas duas partes, existiam um grupo de respostas que eram repetidos em vários perguntas diferentes. No meu caso foi para essa parte de HA, e na parte de Query (a segunda parte da prova). O que predominou nesse assunto foi comparar qual determinada tecnologia é melhor em dada situação. Acho que essa abordagem já é conhecida. Também, me lembro de 1 ou 2 perguntas sobre Failover Cluster, que mantém o mesmo padrão de provas anteriores (gerenciamento do cluster, atualização, fazer o failover, etc.).

Em um mix bem bacana, caiu perguntas sobre PBM, Audit, XE e profiler. A maioria delas te dava uma situação e perguntava qual tecnologia usar. Me recordo de algumas sobre Audit, perguntando sobre a sintaxe para fazer determinada tarefa. Perfmon também deu alguns sinais de vida nesse tipo de questão comparativa.

A outra parte, veio querying pesado. Como eu sou fã da parte de perfomance já adianto que caiu umas bem “desafiadoras”, porém algumas mal formuladas. Em uma dessas, o questão te dava uma querie que usava uma UDF e perguntava qual das opções era a melhor escolha para otimizar a consulta.  Funções analíticas não me recordo de muita coisa, apenas de uma questão, onde você deveria saber a diferença entre LAG E LEAD e o efeito da cláusula OVER sobre ela. (aproveito para compartilhar este artigo do Fabiano Amorim, no simple talk, que te dá uma visao bacana dessa funções e uma boa explicação sobre o conceito do  “frame/window”). Pode crer, este artigo me salvou! Smile

No geral a parte de query caiu perguntas bem conhecidas dos outros exames de query, incorporando algumas com as novas funcionalidades. Dessa vez eu não vi nenhum para fazer a análise de um plano de execução. Mas teve view indexada, data modification, etc.

SSIS teve sua presença em umas 4 ou 5 questões, junto SQL Server Agent, jobs, etc.

Em suma, eu gostei da prova, achei cheia de questões legais e senti uma dificuldade maior do que nas outras provas. Talvez seja porque ainda não estivesse muito em contato com a nova versão do produto ( e já tá vindo a 2014 pra piorar melhorar a minha vida, rs!). Uma dica que eu dou é ver o “What’s New” do 2012, ver o que tem de novo, e estudar esses assuntos (no próprio link tem breve explicações que já ajudam). Tem muita coisa bacana que veio para resolver problemas antigos, assim quem já tem alguma experiência desde a versão 2005, consegue assimilar tranquilo as novas funcionalidades.

No mais é isso galera, até o próximo post. A nossa série sobre o SELECT ainda não parou, em breve a continuação. Quando fizer o Part 2, eu posto aqui os resultados.

Também aproveito para falar que post da parte de administração também estarão em breve saindo do forno. E se você tem alguma sugestão, não deixe de usar o espaço “on demand” para colocar algum assunto. Até a próxima!


[]’s
Rodrigo Ribeiro Gomes

3. Desmistificando O SELECT no SQL SERVER: O FROM

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

E após mais um longo tempo sem postar nada,  vou dando continuidade a nossa série do processamento lógico de um SELECT

Hoje vamos falar sobre o FROM. Neste post eu tentei uma breve explicação sobre o que é o processamento lógico, e a comparação dele com o processamento físico. O objetivo desta série é saber como o SQL Server “entende” uma query e como ele vai manipular as informações para produzir o resultado codificado pelo seu comando de SELECT. De posse desta informação, você pode começar a manipular suas queries e entender porque determinada consulta não está trazendo um resultado que você espera, ou rapidamente poder montar uma consulta que irá trazer os dados corretamente.

A cláusula FROM

A cláusula FROM é a primeira a ser processada. Lá ficam as nossas tabelas e as operações que fazemos com elas.Você pode fazer JOINS, APPLYs e PIVOTs com as tabelas. A fase de processamento do FROM é divido em sub-fases, pois é possível realizar várias operações dentro do JOIN (JOINS, APPLY e PIVOTS). Cada sub-fase também produz uma tabela virtual que é passada para a próxima sub-fase e por ai em diante. No final, a tabela virtual resultante é retornada do FROM e passada para a próxima fase,que é o WHERE (que veremos em outro post). Esta imagem ilustra melhor:

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.

A sintaxe do FROM é a seguinte:

FROM
input OPERAÇÃO input OPERAÇÃO input OPERAÇÃO input [etc…]

Percebam que eu usei o nome “input”. Vou chamar assim porquê esse input pode ser qualquer coisa que retorne uma estrutura de tabela:

  • Uma tabela
  • Uma view
  • Uma tabela derivada
  • Uma CTE
  • Uma Table-Valued Function

Se você não conhece o que são cada um desses itens, não se preocupe. Apenas mantenham em mente que “input” é uma tabela.

A OPERACAO é o que será feito entre os dois inputs. Ela pode ser:

  • JOINS (CROSS,INNER, LEFT, RIGHT,FULL)
  • APPLY (CROSS, OUTER)
  • PIVOT (PIVOT, UNPIVOT)

        As sub-fases da cláusula FROM variam de acordo com cada uma dessas oparações. A sub-fases para um “INNER JOIN” são diferentes para um CROSS JOIN que são diferentes para um “CROSS APPLY” ou um “UNPIVOT”.
Para simplificar, vamos inicialmente falar somente sobre as sub-fases para todos os tipos de JOINS, pois estes são mais fáceis de se compreender e são usados mais frequentemente. Em outro post entraremos em mais detalhes sobre as sub-fases dos outros operadores. Mas o fluxo sempre será o mesmo: o resultado produzido por uma fase, será passado a próxima fase. No FROM, existe uma sub-fases para cada operador de tabela.

Operadores de Tabela

As operações realizada com as tabelas são feitas através de operadores de tabela. Por exemplo, um “INNER JOIN”. Os operadores de tabela seguem algumas regras já conhecida por nós lá na matemática…Por exemplo, você tem a operação “SOMAR”. O que é preciso para fazer uma soma acontecer? Você precisa de 2 números para fazer a SOMA. Neste caso, os 2 números chamamos de “operando” e a “soma” é o operador, o qual é representado pelo sinal “+”. Com tabelas é a mesma coisa. Por exemplo, para fazer um CROSS JOIN, você precisa de dois inputs (duas tabelas). O operador é representado pelo seu próprio nome, ou seja, “CROSS JOIN”. Os dois inputs (as duas tabelas) são os nossos operandos.

Algumas operadores da matemática em comparação com operadores de tabela

Alguns operadores da matemática em comparação com operadores de tabela

Ainda na matemática, se você tem a expressão “1 + 1 + 2″, Você pode fazer “1 + 1″, e do resultado, somar com 2. Ou seja o operador só trabalha com 2 operandos por vez. Igualmente com os operadores de tabela, se existir mais de 2 operandos, é feito a operação entre os 2 primeiros operandos, e o resultado é usado como input da esquerda para o próximo operador, juntamente com o outro input da direita, e por ai vai até acabar:

input_A OPERADOR input_B OPERADOR input_C OPERADOR input_D:

    input_A OPERADOR input_B  = input_AB

    input_AB OPERADOR input_C = input_ABC

    input_ABC OPERADOR input_D = input_ABCD

Como acabou as operações, o resultado seria o “input_ABCD”.

Percebam que o resultado produzido por um operador é usado como input para a próxima operação

Percebam que o resultado produzido por um operador é usado como input para a próxima operação

Lembre-se que podemos misturar operadores de diferentes operações:

A JOIN B APPLY C PIVOT D.

Simplesmente, o resultado do JOIN de A com B é usado para fazer o APPLY com C, e este último resultado é usado para fazer o PIVOT com D.

Existem três grupos de operadores de tabela no SQL Server: JOINS, APPLY e PIVOT. Os Joins combinam linhas de dois inputs, e podem se basear em um condição. O APPLY também combina linhas entre dois inputs, porém ele é um pouco mais avançado e permite executar sub-queries para cada linha. O PIVOT permite transformar linhas em colunas e vice-versa. Para cada uma dessas classes, há algumas sub-fases que são executadas. Isto significa que para cada operador que você usa em sua query, 1 ou mais sub-fases dessas serão executadas. Lembre-se, as sub-fases são executadas para cada operador usado na query. Dependendo do operador usado, algumas sub-fases não precisarão ser executadas e o SQL Server irá avançar para o próximo operador ou finalizar o FROM, caso não haja mais operadores. Mas, de novo, ressalto que por enquanto iremos apenas falar de JOINs.

Na imagem acima podemos observar o que foi dito anteriormente: Cada operador irá executar as sub-fases correspondentes ao seu grupo.

Na imagem acima podemos observar o que foi dito anteriormente: Cada operador irá executar as sub-fases correspondentes ao seu grupo.

AS SUB-FASES DO JOIN

  • 1ª Sub-Fase: Produto cartesiano
    Nesta sub-fase todas as linhas da tabela da esquerda são combinadas com todas as linhas da tabela da direita. O operador CROSS JOIN executa somente sub-fase.
  • 2ª Sub-Fase: Aplicar a “condição” da cláusula ON
    Alguns tipos de JOINS permite que você especifique uma condição, através da cláusula “ON”. Para cada linha resultante da fase anterior, a condição ON será executada e o seu resultado, que só pode ser VERDADEIRO ou FALSO, será salvo em uma coluna interna. Somente as linhas onde o valor for VERDADEIRO serão mantidas e passadas para a próxima fase. O operador “INNER JOIN” executa somente até esta sub-fase.
  • 3ª Sub-Fase: Devolver as “linhas preservadas”
    Alguns joins permitem que todas as linhas das tabelas envolvidas na operação sejam preservadas, mesmo se o filtro ON resultar em FALSO para todas elas. Essas são os OUTERS JOINS (LEFT JOIN, RIGHT JOIN e FULL JOIN). Nesta fase as linhas das tabelas que devem ser preservadas são adicionadas de volta ao resultado. Os operadores “OUTER” mencionados acima executam até esta sub-fase.

Nos próximos posts, vamos detalhar cada uma destas sub-fases. Até lá!

[]’s
Rodrigo Ribeiro Gomes
MCTS | MCITP