Expremendo Performance do
 SQL Server

Felipe Ferreira - @SQLBoy
MCT, MCITP, MCPD, MCTS
http://blogs.solidq.com/fferreira - fferreira@solidq.com
Agenda
  SE TUDO DER CERTO, IREMOS VER:
 Cenário Atual

 Futuro. Se preocupar com detalhes de performance é
  importante?

 Aonde podemos melhorar a performance no SQL Server?

 Considerações de Performance no Design do DB

 Considerações de Performance nas Configurações do DB

 Consultas e Índices
Cenário Atual
 EQUIPES DE DESENVOLVIMENTO

 Equipes não recebem
  treinamento adequado em T-
  SQL

 Equipes de DEV não se
  preocupam com a performance
  do código T-SQL que estão
  escrevendo

 Temos contantemente que
  “apagar incêndios”
Cenário Atual
 ORM’S
                 Muito útil para consultas simples


                 Aumenta a produtividade da
                  equipe

                 A experiência mostra que
                  normalmente geram consultas
                  ruins em casos mais complexos


                 Grande amigo dos consultores de
                  banco de dados 
Futuro
   Azure
   Denali
   PDW
   Performance does Matter!
Performance?
 Otimização dos discos
 Otimização do Windows
 Otimização do serviço do SQL Server
 Otimização do Design da base de
  dados
 Otimização das consultas
 Otimização dos índices
 Etc, etc, etc
Design
 TIPOS DE DADOS

 Campo Idade, precisa ser INT?
  Quantos anos vocês tem?
 Preciso da precisão do DateTime?
 Data type       Range                                                               Storage


 bigint          (- 9,223,372,036,854,775,808) to 9,223,372,036,854,775,807"         8 Bytes


 int             (-2,147,483,648) to 2,147,483,647                                   4 Bytes

 smallint        (-32,768) to 32,767                                                 2 Bytes

 tinyint         0 to 255                                                            1 Byte

 Datetime        1/1/1753 00:00:00.000 to 12/31/9999 23:59:59.997                    8 Bytes

 SmallDatetime   1/1/1900 00:00:00 to 6/6/2079 23:59:59 *arredondamento do segundo   4 Bytes
Design – Tipos de Dados
 EXEMPLO
 Chaves INT
   445MB
 Chaves Uniqueidentifier
   755MB, 70% maior


 Quanto tempo vai levar para inserir 10K linhas
  em cada base de dados?
Overview Demo Tipos de Dados
 O QUE APRENDEMOS NESSA DEMONSTRAÇÃO?



 O tipo de dados escolhido durante o
  design da base de dados importa, e
  vai ser determinante quando vocês
  precisarem escalar a aplicação!
Design
 (DES) NORMALIZAÇÃO


 Em alguns casos, repito, em ALGUNS casos,
  podemos quebrar alguma regra de
  normalização em benefício da performance,
  utilizando colunas calculadas.

 Só deve ser utilizado em casos específicos, em
  tabelas muito grandes, depois de verificado o
  impacto da criação da coluna calculada e índice
Demonstração Normalização
 VAMOS VER NA PRÁTICA



 Demonstração da economia de IO
  que podemos conseguir com a
  criação de uma coluna calculada.
Overview Demonstração
 O QUE VIMOS?


 Podemos conseguir uma economia muito
  grande de IO, mas temos que tomar cuidado
  para que nossa base de dados não vire uma
  “bagunça”

 Temos que lembrar que o novo índice precisará
  de espaço em disco, e terá um custo de
  manutenção
Configurações
    CONFIGURAÇÕES DA BASE



   Auto Create Statistics
   Auto Update Statistics
   Auto Close
   Auto Shrink!
Configurações
 DEMONSTRAÇÃO



 Demonstração de Auto-Shrink
Overview Demo Configurações
 O QUE APRENDEMOS NESSA DEMO?


 Aprendemos que Auto-Shrink é coisa do
  demônio e devemos nos afastar dele!
  Mantenham-se longe do lado negro da
  força!

 Entender as configurações que fazemos
  na nossa base de dados é muito
  importante
Consultas - Índices
  PROFILER, DTA, MISSING INDEXES

 O SQL fornece várias formas de monitorarmos o que
  está acontecendo

 Profiler: capturar consultas sendo executadas

 DTA: sugestões de tunning da base de dados baseado
  nas consultas utilizadas

 Missing Indexes: visualização das sugestões de índices
  que a engine do SQL Server faz baseado nas consultas
  que executamos
Demonstração
 VAMOS VER NA PRÁTICA



 Uso do Profiler
 Uso do DTA
 DMV’s de Missing Index
Overview Demonstração
  O QUE VIMOS?


 Podemos monitorar todo o tráfego do nosso servidor
  através do Profiler


 O DTA facilita nosso trabalho na hora de procurar por
  boas indicações de índices a serem criados


 Além do DTA podemos utilizar as DMV’s para buscar
  nós mesmos por essa informação
Consultas
    ALGUNS ERROS COMUNS EM CONSULTAS



   Uso do CASE com Sub-consultas
   Cuidado com Views
   IN ou BETWEEN?
   TOP 1 ORDER BY OU MAX?
Conclusão
  ALGUEM ACORDADO?


 Performance é um assunto complexo


 Equipe precisa se profissionalizar


 Se vocês não pensarem em performance no começo do
  desenvolvimento, vocês vão sofrer eternamente! 


 O SQL Server faz um ótimo trabalho lidando com os casos
  mais simples, mas podemos usar várias ferramentas do
  produto para analisar a performance das consultas
Recursos Relacionados
 http://blogs.solidq.com/fferreira
 http://blogs.solidq.com/fabianosqlserv
  er
 Hashtag do Twitter: #SQLTipsBR
Obrigado!
Felipe Ferreira - @SQLBoy
MCT, MCITP, MCPD, MCTS
http://blogs.solidq.com/fferreira - fferreira@solidq.com

Expremendo performance do sql server

  • 1.
    Expremendo Performance do SQL Server Felipe Ferreira - @SQLBoy MCT, MCITP, MCPD, MCTS http://blogs.solidq.com/fferreira - fferreira@solidq.com
  • 2.
    Agenda SETUDO DER CERTO, IREMOS VER:  Cenário Atual  Futuro. Se preocupar com detalhes de performance é importante?  Aonde podemos melhorar a performance no SQL Server?  Considerações de Performance no Design do DB  Considerações de Performance nas Configurações do DB  Consultas e Índices
  • 3.
    Cenário Atual EQUIPESDE DESENVOLVIMENTO  Equipes não recebem treinamento adequado em T- SQL  Equipes de DEV não se preocupam com a performance do código T-SQL que estão escrevendo  Temos contantemente que “apagar incêndios”
  • 4.
    Cenário Atual ORM’S  Muito útil para consultas simples  Aumenta a produtividade da equipe  A experiência mostra que normalmente geram consultas ruins em casos mais complexos  Grande amigo dos consultores de banco de dados 
  • 5.
    Futuro  Azure  Denali  PDW  Performance does Matter!
  • 6.
    Performance?  Otimização dosdiscos  Otimização do Windows  Otimização do serviço do SQL Server  Otimização do Design da base de dados  Otimização das consultas  Otimização dos índices  Etc, etc, etc
  • 7.
    Design TIPOS DEDADOS  Campo Idade, precisa ser INT? Quantos anos vocês tem?  Preciso da precisão do DateTime? Data type Range Storage bigint (- 9,223,372,036,854,775,808) to 9,223,372,036,854,775,807" 8 Bytes int (-2,147,483,648) to 2,147,483,647 4 Bytes smallint (-32,768) to 32,767 2 Bytes tinyint 0 to 255 1 Byte Datetime 1/1/1753 00:00:00.000 to 12/31/9999 23:59:59.997 8 Bytes SmallDatetime 1/1/1900 00:00:00 to 6/6/2079 23:59:59 *arredondamento do segundo 4 Bytes
  • 8.
    Design – Tiposde Dados EXEMPLO  Chaves INT  445MB  Chaves Uniqueidentifier  755MB, 70% maior  Quanto tempo vai levar para inserir 10K linhas em cada base de dados?
  • 9.
    Overview Demo Tiposde Dados O QUE APRENDEMOS NESSA DEMONSTRAÇÃO?  O tipo de dados escolhido durante o design da base de dados importa, e vai ser determinante quando vocês precisarem escalar a aplicação!
  • 10.
    Design (DES) NORMALIZAÇÃO Em alguns casos, repito, em ALGUNS casos, podemos quebrar alguma regra de normalização em benefício da performance, utilizando colunas calculadas.  Só deve ser utilizado em casos específicos, em tabelas muito grandes, depois de verificado o impacto da criação da coluna calculada e índice
  • 11.
    Demonstração Normalização VAMOSVER NA PRÁTICA  Demonstração da economia de IO que podemos conseguir com a criação de uma coluna calculada.
  • 12.
    Overview Demonstração OQUE VIMOS?  Podemos conseguir uma economia muito grande de IO, mas temos que tomar cuidado para que nossa base de dados não vire uma “bagunça”  Temos que lembrar que o novo índice precisará de espaço em disco, e terá um custo de manutenção
  • 13.
    Configurações CONFIGURAÇÕES DA BASE  Auto Create Statistics  Auto Update Statistics  Auto Close  Auto Shrink!
  • 14.
  • 15.
    Overview Demo Configurações O QUE APRENDEMOS NESSA DEMO?  Aprendemos que Auto-Shrink é coisa do demônio e devemos nos afastar dele! Mantenham-se longe do lado negro da força!  Entender as configurações que fazemos na nossa base de dados é muito importante
  • 16.
    Consultas - Índices PROFILER, DTA, MISSING INDEXES  O SQL fornece várias formas de monitorarmos o que está acontecendo  Profiler: capturar consultas sendo executadas  DTA: sugestões de tunning da base de dados baseado nas consultas utilizadas  Missing Indexes: visualização das sugestões de índices que a engine do SQL Server faz baseado nas consultas que executamos
  • 17.
    Demonstração VAMOS VERNA PRÁTICA  Uso do Profiler  Uso do DTA  DMV’s de Missing Index
  • 18.
    Overview Demonstração O QUE VIMOS?  Podemos monitorar todo o tráfego do nosso servidor através do Profiler  O DTA facilita nosso trabalho na hora de procurar por boas indicações de índices a serem criados  Além do DTA podemos utilizar as DMV’s para buscar nós mesmos por essa informação
  • 19.
    Consultas ALGUNS ERROS COMUNS EM CONSULTAS  Uso do CASE com Sub-consultas  Cuidado com Views  IN ou BETWEEN?  TOP 1 ORDER BY OU MAX?
  • 20.
    Conclusão ALGUEMACORDADO?  Performance é um assunto complexo  Equipe precisa se profissionalizar  Se vocês não pensarem em performance no começo do desenvolvimento, vocês vão sofrer eternamente!   O SQL Server faz um ótimo trabalho lidando com os casos mais simples, mas podemos usar várias ferramentas do produto para analisar a performance das consultas
  • 21.
    Recursos Relacionados  http://blogs.solidq.com/fferreira http://blogs.solidq.com/fabianosqlserv er  Hashtag do Twitter: #SQLTipsBR
  • 22.
    Obrigado! Felipe Ferreira -@SQLBoy MCT, MCITP, MCPD, MCTS http://blogs.solidq.com/fferreira - fferreira@solidq.com