TSQL Expert– SP, RJ e BSB

Originally posted on Blog - Fabiano Neves Amorim:
Galera, acabei de colocar no site da Sr.Nimbus o calendário para nosso treinamento de T-SQL expert. Seguem mais detalhes: ·         Rio de Janeiro o   SQL11 T-SQL Expert o   Carga horária: 24 horas…

TSQL Expert– SP, RJ e BSB

Galera, acabei de colocar no site da Sr.Nimbus o calendário para nosso treinamento de T-SQL expert. Seguem mais detalhes: ·         Rio de Janeiro o   SQL11 T-SQL Expert o   Carga horária: 24 horas o   Treinamento no período integral aos sábados das 09:00 as 18:00 nos dias 12, 19 e 26 de Outubro de 2013. o   Local: […]

Paralelismo – Parte 5 – Final: Ultrapassando Problemas

Nos primeiros posts desta série, falamos sobre o "Max Degree of Parallelism", que pode ser definido a nível de instância ou a nível da query - com a hint MAXDOP, e sobre o "Cost Threshold For Parallelism". Além destas duas opções, existe a possibilidade de controlar quais processadores lógicos serão utilizados pelo SQL Server, definindo o número de processadores disponíveis, o que irá afectar o paralelismo. Esta opção é a "Affinity Mask".

Antes de mais nada, vamos introduzir mais alguma coisa sobre paralelismo...Hoje em dia, com servidores cheios de CPU (o que tende a diminuir com o novo modelo de licenças), problemas com o paralelismo são comuns. O valor do "Max Degree of Parallelism", que por defeito é 0, geralmente não é suficiente para atender a demanda de sistemas que funcionam com um alto grau de concorrencia. O acesso ao CPU passa a ser custoso, gerando um por vezes uma situação aonde o custo para execução da tarefa principal da query é inferior ao custo do sincronismo do paralelismo - o que é chamado de "Trashing".

O ideal é encontrar um valor óptimo para o "Max Degree of Parallelism". Existem, pela Internet afora, vários artigos tratando deste assunto, porém o que eu verifico no dia-a-dia, são dois tipos de abordagem por parte dos DBAs:


  • Abordagem "drástica":
    Definir o MaxDOP para 1, ou seja, acabar com o paralelismo. Atenção que esta configuração é uma boa prática para algumas aplicações em específico.
  • Abordagem "conservadora":
    Simplesmente ignorar que este parâmetro existe, o que em alguns casos é justificável, pois a instância pode estar a funcionar perfeitamente com pouca carga. Chamo esta abordagem de conservadora, pois do outro lado da moeda, existem DBAs que preferem deixar as definições como vêm "por defeito". A justificativa é: "Se veio assim, é porque a Microsoft sabe o que está a fazer". Bem, se a definição fosse perfeita, provavelmente não daria para alterar :)


Referi que já existem vários artigos abordando o melhor valor para o "Max Degree of Parallelism", mas de qualquer forma deixo aqui a abordagem que adoptei, que é de certa forma flexível - nem drástica, nem conservadora.


  • Se o servidor tem um número de CPUs menor ou igual a 8: MaxDOP = (Número de CPUs)/2
  • Se o servidor tem mais do que 8 CPUs:
  1. MaxDOP=8 como baseline.
  2. Monitorizar o estado dos processos após a alteração.
  3. Se estiver bem, adicionar mais 4 ao valor actual do MaxDOP.
  4. Repetir o ponto 2 e 3 até encontrar um valor óptimo.
  • Se nada disso resolver, considere verificar e/ou alterar o valor do "Cost Threshold for parallelism".



  • Existem formas de passar por cima do limite definido no MaxDOP!
    Temos que ter em mente que, além da já referida "Affinity Mask" afectar o comportamento do MaxDOP, as definições a nível do "Resource Governor" e a HINT MAXDOP ultrapassam o limite definido na opção "Max Degree Of Parallelism".

    O que justificaria tanto trabalho alterando definições?
    Pois é, temos aqui mais um factor! Antes de alterarmos opções a nível da instância, temos que lembrar que todas as BDs e todos os processos irão ser afectados! Este não é apenas um problema para instâncias que hospedam várias bases de dados, pois mesmo em um universo reduzido de uma ou duas bases de dados não faria o menor sentido alterar uma definição global por cause de uma ou duas queries com problemas, certo?

    O resumo de tudo é: Não altere as definições da instância, a não ser que o problema seja global ou que, em caso de aplicações de código fechado, não seja possível alterar as queries, stored procedures, adicionar índices, etc...

    O que fazer então?
    A resposta foi dada acima. A abordagem deve ser feita de um universo reduzido para um universo maior, no nosso caso, de uma simples query até o nível da instância. Então a recomendação é a seguinte:

    1. Identificar as queries com problema e trabalhar uma forma de melhorar a performance, mesmo que seja re-escrevendo toda a query.
    2. Verificar se a manutenção a nível de instância está sendo feita da melhor forma (actualização das estatísticas, defrag e rebuild de índices).
    3. Verificar se o servidor, no geral, não tem problemas de I/O, isso inclui não apenas problemas de hardware, mas também o número de discos dedicados ao SQL Server, a distribuição de ficheiros, etc.
    4. Se o problema ainda não tiver sido resolvido, ajustar a query com um valor óptimo de paralelismo, utilizando a HINT MAXDOP. Assim, somente a tal query irá ser afectada.
    5. Definir regras utilizando o "Resource Governor", limitando o MaxDOP de uma forma mais global, mas mesmo assim num âmbito menor do que a nível de instância.
    6. Se ainda assim, o número de queries com problemas for muito grande, podemos elevar o detalhe de alteração ao nível da instância.


    Chegamos ao fim desta série!! Agradeço a quem acompanhou até o fim e me disponibilizo para responder a alguma dúvida!!

    Um Abraço a até a próxima (semana que vem :).

    Muitos VLF’s podem degradar a performance da sua instância do SQL Server!


    Olá pessoal tudo certo? Espero que sim!

    Hoje irei falar sobre um assunto já bastante discutido entre a comunidade relacionado a perda de performance no ambiente devido a uma grande quantidade de VLF’s (Virtual Log Files) no log de transações das bases de dados.

    O Engine do SQL Server divide cada arquivo físico de log internamente em um determinado número de VLF’s. Estes não possuem um tamanho fixo nem uma quantidade padrão para cada arquivo físico de log. O engine escolhe dinamicamente o tamanho dos VLF’s quando o arquivo de log é criado ou passa por uma expansão.

    Se as configurações de auto-growth dos arquivos de log não estiverem bem definidas, você irá ter o log de transações com uma quantidade muito grande de VLFs e que irá ficar fragmentado com uma frequência maior, o que pode ser extremamente prejudicial à performance do processo de recovery e atividades relacionadas à replicação.

    Primeiramente, vamos entender como são adicionados os VLF’s que passam por uma expansão, usando como referência o post da Kimberly Tripp (SQL Skills):

    Expansões menores que 64MB e até 64MB = 4 VLFs serão adicionados.
    Expansões maiores que 64MB e até 1GB = 8 VLFs serão adicionados.
    Expansões maiores que 1GB = 16 VLFs serão adicionados.

    Agora, vamos listar o que muitos VLF’s em um arquivo de log podem vir a causar:

    1 – Lentidão no backup do transaction log: No processo de backup todos VLF’s presentes no log serão lidos antes da operação iniciar.

    2  - Lentidão no processo de recovery da base de dados: Na primeira fase do processo de recovery das bases de dados chamada de Discovery, todos os VLF’s nas logs serão lidos e uma lista deles será montada para que a operação se inicie, muitos VLF’s podem vir a prejudicar a performance desta operação. Veja mais informações sobre nos links abaixo:



    3 – Lentidão em uma replicação transacional: O log reader realiza a leitura dos arquivos de log varrendo os VLF’s, logo muitos VLF’s podem onerar o processo e prejudicar a replicação dos dados como um todo.

    4 – Lentidão nas operações de insert/update/delete: Recomendo a vocês a realizar o teste proposto pelo Linchino site abaixo para evidenciarem o problema neste caso:
      

    Portanto, a recomendação é que você mantenha os seus logs sempre com uma quantidade de VLF’s razoável. Você pode verificar a quantidade de VLF’s de um banco de dados através do comando DBCC LOGINFO. Se você já possui o log de transações com muitos VLF’s e deseja reduzir a quantidade dos mesmos, você deve fazer o shrink do arquivo com o log de transações, e expandi-lo numa única operação para o tamanho desejado / necessário para suportar a carga de trabalho.
     
    Outros links utilizados de referência para escrita deste post:

    http://www.virtualpass.com.br/

    Função Escalar x Table Valued Function

    Muito se fala na internet sobre como as funções escalares são terríveis e que devemos evitar o uso a todo o custo… Eu gostaria de mostrar o porquê: Vejam o seguinte script abaixo (um procedimento muito utilizado por aí: a utilização de uma função escalar que trata “N” casos e retorna o valor desejado). Primeiro, […]

    Identificar o ponto exato de execução de um statement

    Esta procedure permite identificar a instrução exata que está sendo executado por uma conexão através do SPID. Semelhante ao DBCC …

    Continuar lendo

    In-Memory a.k.a OLTP “Hekaton” – Deep Dives [1]

    Armazenamento In-Memory   O armazenamento de tabelas e indices são lidados de forma diferente quando estamos utilizando essa nova tecnologia do XVelocity, tabelas que são otimizadas para estarem em memória (memory-optimized tables) não são armazenadas em páginas como no modelo baseado em armazenamento em disco (disk-based tables) a grande diferença é que registros de uma […]

    Retornando o status do serviço via PowerShell

    Olá pessoal, Passando aqui apenas para compartilhar mais um simples script PowerShell com vocês. A intenção do script é varrer uma lista de servidores de SQL Server e retornar apenas os serviços que estiverem com o status de stopped. O Script utiliza o cmdlet Get-Service. $Servers = Get-Content ‘C:\temp\Servers.txt’ $Outputfile = "C:\temp\SQLServerServiceStatus.txt" ForEach($Server in $Servers){ … … Continuar lendo

    TechED 2013 – O rescaldo

    E assim se concluiu mais um evento TechED Europa onde a "moda" continua a ser Big Data, novas funcionalidades dos novos produtos e Azure, Azure, Azure...

    Não esquecer que todas as sessões já se encontram disponíveis gratuitamente no sítio do Channel 9 onde calmamente podemos assistir a todo conteúdo do evento.

    Gostava de aproveitar o post de hoje para sugerir alguns oradores cujas sessões durante o evento estavam completamente cheias:

    • Mark Russinovich: Uma das referencias mundiais do mundo de IT e o criador das ferramentas Sysinternals (ver info);
    • Andy Malone: Apresentador nato reconhecido mundialmente tem um conjunto de sessões memoráveis sobre segurança (ver blog)
    • Paula Januszkiewicz: Outra oradora sobre temas de segurança que teve que repetir as suas sessões devido à adesão que teve (ver site)
    Esperemos que gostem e não percam esta oortunidade de revisitar os conteúdos do Tech Ed Europe gratuitamente em http://channel9.msdn.com/Events/TechEd/Europe/2013.

    TechEd 2013 – parte ultima

    Uma última nota sobre este TechEd: Valeu a pena? Sim! Por poder falar com alguns IT Pros, e perceber o que são algumas das tecnologias emergentes (que no dia a dia não existe tempo para tal!).

    Por outro lado não deu para deixar de notar a fraca afluência de publico (~4k? onde 7k seria um mais esperado), e uma presença de Portugueses menor do que vi em outros TechEds.

    Mais algumas dicas:
     e mais umas fotos

    SQL2014, teve afluência




    Expositores




     1/3 da sala keynote



    data mining não chama multidões


    uma boa definição de BigData


    o sócio do M.Russinovic


     e Design no TechEd


    !
    Go to Top