set 16

Análise de Lentidão – II

Mais um caso interessante onde a soma de fatores fez com que uma transação que deveria demorar 1 segundo demorasse mais de uma hora, mesmo com memória de sobra, processamento abaixo dos 10% e nenhum usuário conectado além do administrator.

 

 

 

 

Cenário

1.   SQL Server 2008 R2 Standard com Failover Cluster em um par de servidores Dell R720, 2x Xeon de 6 cores (24 com HT), 96GB de RAM, 1 volume de 1TB (unidade S) em storage High-end conectados através de fibra em HBA Dual, onde se concentram todos os arquivos do SQL Server de dados e TLog;

 

2.   Os servidores ainda não estavam em produção, durante a fase de testes observou-se lentidão generalizada na aplicação, principalmente em uma query específica que fazia apenas um SELECT de 38colunas de 5 tabelas. Esta query utiliza a cláusula WHERE ao invés de INNER JOIN, fazendo um sort com ORDER BY em 4 colunas;

 

3.   O tempo da query variava de 35 a 75 minutos e era executada enquanto nenhum outro usuário estava conectado na instância;

 

4.   Em outros ambientes a mesma query era retornada em menos de 1 segundo;

 

5.   O servidor ficou meses parado e tinha 48 horas para entrar em produção;

 

 

Simulação

Para simular o problema neste cenário era muito simples, bastava executar a query fornecida pelo fabricante da aplicação. Com os contadores do Perfmon configurados a query foi executada sozinha e depois de um intervalo, quatro conexões simultâneas executaram a mesma query, acentuando ainda mais as evidências.

 

Análise

Costumo configurar o Perfmon para exibir os últimos 10 minutos e de olho nos gráficos durante a primeira execução da query foi possível observar um consumo relativamente alto de I/O na unidade S (volume de 1TB), se pensarmos que é apenas uma query sendo executada sem concorrência com outros usuários, praticamente sem consumo de CPU e memória. Então a mesma query foi executada por 4 processos simultaneamente e ficou bem mais evidente. Vejam que o tempo de disco e o consumo de IOPS ocasionam uma fila média de quase 6,5:

 

Tempo de disco e IOPS

 

Fila de CPU

Fila de CPU

 

Consumo de Memória

Consumo de Memória

 

Buffer Manager

Buffer Manager

 

Vejam que realmente não temos atividade no servidor:

 

Atividade

 

Com estas informações (e olhando o contador Page File Usage %) dá pra perceber que não é paginação, mas com Cache Hit Ratio em 100,00% cravado fica difícil entender o que é que está sendo buscado no disco que consome tanto I/O, ainda mais depois de executar a mesma query repetidas vezes. Consultando as esperas tivemos um resultado interessante: 

Ao invés de encontrar PAGEIOLATCH, a espera era por IO_COMPLETION. Acompanhando a utilização da TempDB vemos que por conta do SORT em 4 colunas há um consumo de cerca de 1GB no arquivo de dados e 24MB de TLog, que está com tamanho inicial de 1MB e Autogrowth de 10%:

TempDB antes

TempDB antes

TempDB durante

TempDB durante

TempDB depois

TempDB depois

Vamos aproveitar pra lembrar que a TempDB, apesar de estar com o Recovery Model em SIMPLE, possui um comportamento diferente das bases de usuário. Como a TempDB é refeita a cada inicialização da Instância, não é feito o auto-checkpoint ao final da transação e o checkpoint também não obedece a configuração do Recovery Interval. Isso significa que a TempDB mantém páginas sujas e evita tocar o disco para gravá-las, já que são temporárias. Este comportamento resulta em utilização diferenciada do TLog, mantendo até os VLFs de transações comitadas marcados como ativos. No caso de TLogs com VLFs pequenos (fácil de supor pelo tamanho inicial e configuração de Autogrowth) a fragmentação pode ser um problema.

Em virtude do resultado do Perfmon somado com a informação de que o servidor ficou meses parado, o primeiro passo foi analisar a storage. Storages High-end se utilizam de diversas tecnologias para proporcionar melhor performance e uma delas é chamada popularmente de “Tierização”. Cada fabricante dá um nome diferente, a HP chama de Adaptive Optimization, a Dell chama de Optimize Data Placement, mas o princípio é o mesmo. São Tiers compostos por discos de performance diferentes, onde dados mais acessados ficam nos discos mais velozes, com RAIDs mais performáticos enquanto dados pouco acessados vão descendo até serem alocados em discos mais simples, utilizando RAIDs voltados apenas a redundância. 

Manualmente o volume foi forçado a ficar no Tier mais veloz e o cenário mudou, melhorando a performance do disco mas ainda com resultado insatisfatório. Vejam agora quantos IOPS conseguimos e o tempo de disco com a mesma query rodando em 4 sessões simultaneamente:

 

Disco depois

Disco depois

 

Conseguimos reduzir drasticamente o tempo de disco e obtivemos um aumento na quantidade de IOPS, o que comprova que o volume está mais performático. Porém, apesar de reduzir o tempo da query de minutos para segundos o resultado ainda era insatisfatório.

Não temos nenhum outro tipo de espera, exceto de Log Flush, levando em consideração a quantidade de transações por segundo:

Log Flush Wait Time

Log Flush Wait Time

 

Wait Stats

Wait Stats

 

Já que esta query era executada em menos de 1 segundo em outros ambientes sugeri a comparação dos Planos de Execução, onde pude constatar uma grande diferença na quantidade de linhas retornadas. Enquanto eram trazidas 200 linhas nos ambientes utilizados como parâmetro na comparação, no nosso caso eram retornadas mais de 4.000 linhas. Relacionando este fato com o espanto do desenvolvedor pela quantidade de linhas, pudemos concluir que a base estava poluída com informações utilizadas por testes anteriores.

 

Recomendações

1.   Criar uma nova base, eliminando a poluição da base com informações de testes;

2.   Dividir este volume de 1TB em outros volumes menores, separando arquivo de dados, TempDB e TLog;

3.   Configurar os arquivos de TLog para um tamanho inicial e crescimento adequados, visando diminuir a quantidade de VLFs e de operações de crescimento do arquivo;

4.   Adicionar 7 arquivos à TempDB, apenas preventivamente, com a finalidade de evitar contenção de GAM, SGAM e PFS. Configurar a trace flag 1117, para garantir a eficiência da utilização dos arquivos de dados;

5.   Adicionar o direito de Perform Volume Maintenance Tasks para o usuário do serviço do SQL Server, possibilitando que as operações de crescimento dos arquivos de dados sejam beneficiadas pelo recurso Instant File Initialization;

6.   Substituir a edição do SQL Server para Enterprise, para tornar disponíveis recursos como mais de 64GB de RAM, utilização dos 12 cores físicos disponíveis, Enhanced Read-Ahead Scan, além das opções de disponibilidade para ambientes críticos como Parallel Index Operations, Parallel Consistency Checks (DBCC) e Partitioning;

 

 

Resultado

De todas as recomendações, apenas a recriação das bases pôde ser aprovada de imediato, trazendo realmente para o resultado esperado menor que 1 segundo. Porém, ficou evidente o que pode acontecer se as demais recomendações não forem implantadas.

Assim que todas as ações forem concluídas trago o resultado.

set 12

Perdeu uma base de sistema?

Talvez por administrar um grande parque de servidores de diferentes empresas de diversos portes, tive a oportunidade de atuar na recuperação de algumas bases de sistema e aqui vai um passo a passo que pode economizar bastante tempo.

As causas são muitas e na maioria das vezes os sintomas são de arquivos corrompidos com logs que são claros, como no nosso exemplo. O Event ID 9004 registra o erro e informa que não foi possível processar o log da base model:

 

Apesar do evento sugerir um restore ou um rebuild do log, como o serviço do SQL não iniciava foi preciso fazer um rebuild das bases de sistema. Como não é possível escolher a base a ser reconstruída, todas as bases de sistema são afetadas – master, model, msdb e tempdb – resultando em consequências como perda de logins e users, bases, endpoints, linked servers, configurações e metadados da instância, o modelo inicial utilizado para criar a TempDB durante a inicialização, jobs, schedules, configurações de service broker entre outras coisas, exceto os objetos de sistema que são armazenados na resource database.

Ficou claro a importância de sempre fazer backup das bases de sistema? Também é interessante aproveitar pra copiar os mdf e os ldf das bases de sistema naquela janela que vai precisar reiniciar o serviço do SQL Server, seja o motivo que for. De posse desses arquivos, eu poderia simplesmente substituí-los e iniciar a instância tranquilamente, praticamente sem impacto.

O procedimento até que é simples mas para quem está em um ambiente de Failover Cluster tem uma dica importantíssima que vamos falar mais adiante.

 

1- Saiba a versão do SQL Server que você está recuperando. Basta olhar nos logs o Event ID 17069 que você fica sabendo exatamente a versão:

 

2- Através da mídia de instalação do SQL Server da mesma versão que está sendo recuperada execute o seguinte comando:

Setup /QUIET /ACTION=REBUILDDATABASE /INSTANCENAME=MSSQLSERVER /SQLSYSADMINACCOUNTS=DOMAIN\ADMINISTRATOR /SAPWD=N0v@S&nh@

Se sua instância for nomeada, troque MSSQLSERVER pelo nome da instância que você obtém facilmente através da console de serviços do Windows;

Troque DOMAIN pelo nome do seu domínio e coloque um usuário para se tornar membro da Role Sysadmin. No caso de um servidor local troque DOMAIN pelo nome do servidor;

A senha do SA é opcional mas é uma boa oportunidade pra já deixá-la definida;

Muitos procedimentos na internet sugerem a utilização do arquivo local que fica em C:\Program Files\Microsoft SQL Server\100\Setup Bootstrap\Release mas no SQL Server 2008 R2 resulta em erro. Em uma thread no Technet vários DBAs informaram que só funcionou depois de utilizarem o setup.exe do CD de instalação. O Tibor Karaszi dá uma explicação pra isso neste artigo (em inglês) e a Microsoft confirma o bug nesta thread do Connect (em inglês). Por isso, o rebuild deve ser iniciado utilizando o CD de instalação do SQL Server da versão que você possui instalada.

 

O comando quando executado com sucesso não retorna nada, apenas volta para o prompt.

 

Rebuild concluído, se você iniciar os serviços vai perceber que falta muita coisa e que só é possível fazer login com o usuário que você adicionou durante o rebuild ou com o SA, usando a senha redefinida. Não inicie o serviço do SQL ainda, vai ser necessário utilizar um parâmetro para possibilitar que a instância seja iniciada em modo Single User, ou seja, apenas um usuário poderá estar conectado.

Para iniciar a instância em modo Single User muita gente indica colocar o parâmetro “-m;” no serviço do SQL Server , permitindo que apenas um administrador se conecte para fazer o restore. Este procedimento não funciona se você estiver em um ambiente com Failover Cluster pois quando você sobe o serviço do SQL Server o serviço do Cluster se conecta assim que o serviço do SQL Server é iniciado, o que te impossibilita de se conectar para fazer o restore. Portanto, vamos para o procedimento que funciona em servidores Standalone e em ambientes com Failover Cluster.

 

3- Abra o prompt e inicie o SQL Server em modo Single User:

C:\> NET START MSSQLSERVER /m
(troque MSSQLSERVER pelo nome da sua instância se for do tipo nomeada)

Desta forma, somente o serviço do SQL Server é iniciado, o serviço do Cluster não percebe e você pode se logar utilizando o SQLCMD da seguinte forma:

C:\> SQLCMD -E -S MSSQLSERVER
(troque MSSQLSERVER pelo nome da sua instância se for do tipo nomeada)

 

4- Agora faça o restore da Master como se estivesse fazendo o restore de uma base de usuário:

1> RESTORE DATABASE master FROM DISK = ‘D:\backups\master.bak’ WITH REPLACE;
2>GO 

 

5- Pare a instância que está em modo Single User:

C:\> NET STOP MSSQLSERVER
(troque MSSQLSERVER pelo nome da sua instância se for do tipo nomeada)

 
6- Agora se você estiver em um ambiente que utiliza Failover Cluster, basta iniciar o serviço na própria console do Cluster. Quem está fazendo em servidor Standalone basta executar:

C:\> NET START MSSQLSERVER
(troque MSSQLSERVER pelo nome da sua instância se for do tipo nomeada)

 

Conecte-se utilizando o SSMS e veja que agora as bases de usuário, configurações e logins estão todos de volta.

 

Referências:

 

Cluster

http://technet.microsoft.com/en-us/library/ms188236.aspx

 

Rebuild

http://technet.microsoft.com/en-us/library/dd207003(v=sql.105).aspx

 

Single User

http://technet.microsoft.com/en-us/library/ms180965(v=sql.105).aspx

 

Restore

http://technet.microsoft.com/en-us/library/ms190679(v=sql.105).aspx

set 06

Treinamento PowerShell 3.0 Online

Estão abertas as inscrições para o primeiro treinamento de PowerShell online ministrado por ninguém menos que Laerte Junior, PASS Regional Mentor, autor no Simple-Talk além de ser uma referência de PowerShell no Brasil.

Como já disse Jeffery Snover, o criador do PowerShell, “se  você não quer estar for a do Mercado de IT nos próximos 5 anos aprenda Powershell.”

 

 

Posh01 – PowerShell 3.0 Fundamentals

Objetivo

Ensinar de forma sólida os fundamentos da programação no PowerShell, cobrindo desde a introdução da console e cmdlets, uso de variáveis, array e hashtables, classes, objetos e seus métodos e propriedades, operadores e controle do fluxo da execução, sempre discutindo a arquitetura e filosofia do PowerShell.

Duração

16 horas.

Público Alvo

Administradores, engenheiros de banco de dados e sistemas, desenvolvedores e todo aquele que deseja ter uma introdução sólida ao mundo do PowerShell e seu modelo programação.

Pré-requisitos

Fundamentos de programação.

Bibliografia

Windows PowerShell in Action 2 ed (Manning: ISBN 9781935182139)

Nível do treinamento

Básico (200)

Módulo 01: Apresentando o PowerShell

  • Fundamentos  do  PowerShell
    • Arquitetura – Core Concepts
    • O que são  Cmdlets ?
    • Parsing e PowerShell
    • Consistencia – Como funciona o Pipeline

Módulo 02: Interagindo com o PowerShell

  • Executando  comandos
    • Gerenciando arquivos e folders
    • Instrodução a PSDrives
    • Suporte a commandos  externos
    • Top 20 cmdlets (Get-Help,  Get-Command, Get-Process, etc.)
    • Usando parâmetros (nomeados, posicional, switch, etc.)
    • Apelidos – atalhos para os Cmdltes
      • Usando, criando e removendo apelidos
      • Definindo apelidos permanentes
      • Rodando arquivos e scripts
      • Rodando powerShell scripts
        • Segurança do sistema
        • Seu primeiro “Hello World”
        • LAB

Modulo 03: Variáveis

  • Variáveis
    • Selecionando nome
    • Atribuindo valores e múltiplos valores
    • Atribuindo retorno de cmdlts a variáveis
    • Concatenando variáveis
    • Listando Variáveis
      • Procurando e eliminando variáveis
      • Variáveis de Ambiente
        • Listando e modificando variáveis de ambiente
        • Escopo de variáveis
          • Restrição automática
          • Modificando a visibilidade de uma variável
          • Configurando o escopo
          • Usando aspas duplas e aspas simples
          • Trabalhando com o null
          • LAB

Módulo 04: Array e tabela hash

  • Trabalhando com arrays
    • Descobrindo arrays
    • Processando arrays no Pipeline
    • Arrays polimórficas
    • Arrays de um elemento
    • Endereçando elementos das arrays
      • Múltiplos elementos
      • Adicionando ou removendo elementos
      • Atribuindo retorno de cmdlts a arrays
      • Usando tabelas hash
        • Criando tabelas hash e seus objetos
        • Manipulando elementos
        • Gravando Arrays em Hash Tables
        • LAB

Módulo 05: Trabalhando com objetos

  • O que é e como trabalhar com objetos
  • Propriedades
    • Propriedades contendo objetos
    • Propriedades read-only e read-write
    • Listando propriedades
    • Métodos
      • Definindo métodos
      • Chamando métodos (com e sem argumentos)
      • Trabalhando com objetos vivos
      • Usando métodos estáticos
        • Tipos .net interessantes
        • Criando novos objetos
          • Usando construtores
          • Carregando assemblies
          • LAB

Módulo 06: Condições, operadores e controle de fluxo

  • Criando Condições
    • Operadores lógicos e de comparação
    • Comparações com arrays
    • Usando o cmdlet Where-Object
      • Filtrando resultados no pipeline
      • Colocando uma condição
      • If-elseif-else
      • Do e While
        • Continuando e parando condições
        • Variáveis como critério de continuação
        • Finalizando Loops sem critério de continuação
        • For
          • Utilização básica e cenários inusitados
          • Foreach
          • Foreach-Object
          • LAB

 

Quem tiver interesse deve entrar em contato direto com o Laerte através do email laertesqldba@outlook.com.

 

(*) Descrição dos níveis do treinamento: os treinamentos são classificados com um nível variado, entre 100 e 400, dependendo da complexidade do curso. O nível 100 representa uma introdução com apresentações mais simples sobre um determinado tema, enquanto o nível 400 representa um conteúdo avançado, como análise detalhada da tecnologia e debugging.

set 02

Análise de Lentidão

 

 

Vamos relatar um caso real de análise de lentidão, chegando a dar timeout em alguns casos e registrando deadlocks:

 

 

 

Cenário

 

1.   A carga é realizada em lote através de um TXT, com centenas ou milhares de transações tratadas pela aplicação, enviadas à Secretaria da Fazenda e registradas na base NFE;

 

2.   Operações similares são realizadas na base NFE_LOJA que fica na mesma instância, porém, de forma distribuída ao longo do dia, individualmente e não em lote. Neste caso sem apresentar erros, ou seja, a lentidão é em uma base específica chamada NFE;

 

3.   A aplicação é capaz de registrar em log o momento que ocorre os deadlocks;

 

4.   Os deadlocks ocorrem sequencialmente dentro do mesmo minuto, em horários variados, e não existem Jobs agendados nestes momentos;

 

5.   O problema passou a ocorrer há cerca de dez dias, quando também ocorreu um incidente de falta de espaço em disco no servidor de aplicação

 

6.   Apesar da lentidão, não havia indícios sobre consumo excessivo de CPU e memória;

 

Simulação

 

Para que fosse possível analisar, foi realizada uma carga com cerca de 700 transações comerciais por volta das 11:00. Neste momento, foi possível identificar que a quantidade de IOPS solicitada era superior a 3.000 e que havia um enfileiramento médio de disco entre 500 e 600.

 

Uma nova base chamada NFE2 com a mesma estrutura da base NFE foi criada, no mesmo volume da base NFE que neste momento possuía 80GB, para realizarmos os testes. Diversas cargas superiores à realizada as 11:00 foram feitas na base NFE2 mas neste caso, a média de consumo de IOPS se manteve inferior a 100 todo o tempo. Enquanto vários dados do perfmon e DMVs estavam sendo coletados, foi feita uma análise nas consultas, verificando quais consumiam mais recursos como CPU e disco. A consulta TOP consumia tanto recurso que era absurdamente maior que a segunda consulta da lista, ordenada pela quantidade de operações de escrita e também em uma segunda lista ordenada por tempo de CPU. A comparação de custo entre a base vazia e a base com 80GB de dados era gritante, 335 contra 2,7.

 

Análise

 

A query fazia um select de 17 colunas, usando a coluna STATUS como predicado na cláusula WHERE. Porém, o índice criado para esta consulta era do tipo não-cluster, ou seja, já que não foram adicionadas as outras 16 colunas explicitamente através da cláusula INCLUDE, só eram encontrados os dados referente a coluna STATUS e um ID do índice cluster, onde uma nova consulta teria que ser realizada para obter os dados das outras 16 colunas e responder à aplicação.

 

A primeira leitura do índice é chamada de Index Seek, pois os dados estão mapeados de acordo com os dados da coluna STATUS. Em seguida, o redirecionamento ao índice cluster pra pegar os dados é chamado de Bookmark Lookup até que linha a linha são montadas, operação chamada de Nested Loops.

 

Mas será que não seria mais fácil, já que o índice cluster possui todos os dados, por que não ler direto o índice cluster todo (este sim possui todas as colunas da tabela), retornando as 17 colunas onde o STATUS seja igual a 1? É exatamente isso que o Query Optimizer do SQL Server faz: quando recebe a query o Query Optimizer cruza as informações com as estatísticas e se for mais barato verificar direto o índice cluster ele então o faz! Esta operação é chamada de Index Scan.

 

Além de mais custosa, esta query era uma das mais executadas. Seu resultado era consumido por outra query que aguardava estas informações para escrever na própria tabela consultada e em outras tabelas da mesma base. Aí foi possível entender a origem dos deadocks, onde queries lentas estavam causando enfileiramento, aguardando liberações de locks do mesmo objeto e dependendo disso para prosseguir.

 

Analisando os dados do Perfmon e DMVs coletados, foi possível identificar um elevado número de solicitações de locks, onde a principal espera das threads era LCK_M_S, ou seja, Shared Lock. No nível de isolamento padrão do SQL Server (Read Commited) as consultas precisam ler dados consistentes e para garantir que não estão sendo alterados durante a leitura os bloqueia antes de ler.

Isso permite que somente quem também queira ler aquele dado possa usá-lo mas quem pretende inserir, atualizar ou deletar dados deve aguardar até que a operação de leitura seja concluída e assim o lock liberado. Portanto, tendo queries querendo ler enquanto outras querem escrever nas mesmas colunas da mesma tabela de forma intensa e sem o índice adequado explica a lentidão de acordo com a quantidade de dados. Tanto as operações de leitura quanto as de escrita demoram mais utilizando o pior plano de execução, fazendo assim com que as demais queries fiquem aguardando ou passem a depender do mesmo dado, resultando em deadlock.

 

Ainda de acordo com o Perfmon e as DMVs, cruzando com as configurações da base e da instância, foi possível perceber que os arquivos de TLog estavam fazendo operações de crescimento muito pequenas (10MB), porque todas as noites era feito o backup do TLog e uma operação de Shrink, reduzindo-o para 10MB novamente (seu tamanho inicial).

 

A TempDB era responsável por cerca de 40% das transações por segundo e estava utilizando apenas um arquivo no mesmo volume da base NFE (que já sofria de consumo de I/O). Seu arquivo de TLog e dados também estavam configurados para crescer a cada 10MB. Como não estava configurado o direito de Perform Volume Maintenance Tasks, as operações de crescimento do arquivo de dados estavam muito mais custosas.

Outros itens foram verificados mas não davam indícios de problemas, portanto vamos deixar de lado para não deixar o texto ainda mais longo.

 

Recomendações 

 

1.   Recriar o índice não-cluster adequadamente, incluindo as outras 16 colunas solicitadas, em outro volume dedicado a este data file, com operações de rebuild agendadas, fazendo testes com o fill factor em 80% 70% e 60% neste índice, já que teremos operações de carga frequentes e desordenadas;

2.   Particionar a tabela, mantendo os dados antigos em arquivos e volumes diferentes, possibilitando que alguns fiquem em modo somente leitura. Desta forma a estratégia de recuperação de desastres receberia uma melhoria significativa, além do processo de rebuild dos índices;

3.   Configurar os arquivos de TLog para um tamanho inicial e crescimento adequados, visando diminuir a quantidade de VLFs e de operações de crescimento do arquivo;

4.   Passar a fazer backups do TLog com intervalos regulares menores, também no intuito de diminuir a quantidade de operações de crescimento do arquivo mas com o benefício de combater sua fragmentação;

5.   Adicionar 7 arquivos à TempDB, já que sustenta 40% das transações, com a finalidade de evitar contenção de GAM, SGAM e PFS. Configurar a trace flag 1117, para garantir a eficiência da utilização dos arquivos de dados.

6.   Transferir os arquivos de dados da TempDB para um volume dedicado, pois os números de IOPS e fila de disco no volume atual são muito expressivos.

7.   Adicionar o direito de Perform Volume Maintenance Tasks para o usuário do serviço do SQL Server, possibilitando que as operações de crescimento dos arquivos de dados sejam beneficiadas pelo recurso Instant File Initialization;

8.   Realizar testes utilizando o Read Commited Snapshot Isolation. Este recurso faz uma cópia dos dados soicitados por uma query na TempDB, reduzindo drasticamente a quantidade de locks, mas aumentando a quantidade de transações na TempDB e consequentemente a quantidade de IOPS.

 

Ainda não obtive um retorno de quais ações de fato foram tomadas e como ficou este caso mas assim que souber postarei o resultado.

 

Este foi um exemplo de como uma análise pode ser longa, podendo tomar caminhos ou linhas de raciocínios diferentes conforme os sintomas apresentados inicialmente, já que muitos fatores devem ser analisados tomando bastante tempo.

Se ficou alguma dúvida não deixe de comentar!

 

set 01

SQL Saturday #245 – como foi

Pra quem não foi no SQL Saturday #245 realizado pelo PASS em conjunto com a comunidade no Rio de Janeiro em 31/08/2013, estamos trazendo um pouco do que foi este grande evento que trouxe palestrantes de todo o Brasil.

 

O que impressionou logo no começo foi a quantidade de pessoas que compareceram para prestigiar e aprender em pleno sábado ensolarado. Olha só o tamanho da fila pra entrar, mesmo tendo bastante gente atendendo e fazendo com que a fila andasse bem rápido. Dá gosto ver eventos assim, onde a divulgação foi bem feita e mostrando a credibilidade do SQL Saturday.

 

Olha a quantidade de gente atendendo e ajudando no fornecimento das credenciais e do material muito bacana, com os contatos de todos os palestrantes e comunidades, um eBook gratuito da O’REILLY entre uma lista enorme de opções (demorei meia hora pra escolher), material da Universidade Veiga de Almeida que hospedou o evento, um resumo sobre o PDW do SQL 2012 e uma licença gratuita do software xSQL Data Compare.

 

A abertura foi feita pelo Chapter Leader do PASS no Rio de Janeiro Dennes Torres, também Diretor da Búfalo Informática, que gentilmente cedeu uma série de kits de brindes que, entre vários ítens, possuíam um treinamento gratuito em DVD.

Érika Madeira

 

A primeira sessão que assisti foi da Érica Madeira, sua primeira apresentação no SQL Saturday mas com bastante experiência de outros eventos, falando sobre as novidades do SQL Server 2014, Big Data, Data Quality, sobre o PDW do material que era entregue na entrada e mostrando de uma forma bem divertida o Plugin para o Excel do Analytics for Twitter.

 

Luan Moreno

Foi bem legal porque logo depois veio o Luan Moreno, que tive o prazer de rever depois do InternalOps, detalhando tecnicamente o funcionamento da tecnologia In-Memory do SQL Server 2014 com Hekaton e  Hash Index. Fez demos e mostrou um insert de meio milhão de registros em 06 segundos, no seu próprio notebook, respondendo um monte de perguntas que os participantes fizeram.

 

 

Durante a pausa pro almoço foi possível ver que o evento realmente estava cheio mas o principal foi poder conhecer pessoalmente o Marcos Freccia que apresentou uma sessão de introdução a queues e wait types, o Nilton Pinheiro que apresentou uma sessão sobre Troubleshooting for Microsoft SQL Server 2005/2008/2012, o Diego Nogare que mostrou por onde começar com o Big Data, além do Marcus Vinícius Bittencourt e do Marcelo Fernandes que fizeram as duas últimas sessions que participei. Não dá pra conhecer todo mundo em um evento só mas nos próximos espero poder conhecer outros feras como o Gustavo Maia Aguiar que falou sobre Concorrência, RCSI e SIL e o Fabiano Neves Amorim, que mostrou as novidades do Query Optimizer no SQL Server 2014. Tive a oportunidade de conhecer também a Karla Landrum e ganhei um dos melhores brindes que estavam distribuindo, um DVD com as best of do PASS Summit 2012 com 10 sessões sensacionais que vou começar a assistir ainda hoje.

 

Oduvaldo ZeferinoNa volta do almoço foi a apresentação do pessoal da Mainwork, mostrando o Ignite da Confio funcionando. Por acaso tinha comentado com o Luan Moreno na hora do almoço sobre esta ferramenta que tive a oportunidade de utilizar, fica aí o link como recomendação desta ótima ferramenta para quem ainda não conhece.

 
 

Marcelo FernandesNa sala lotada e prendendo a atenção de todos com uma apresentação muito bem elaborada e bem completa estava o Marcelo Fernandes falando sobre Alta Disponibilidade de uma forma bem abrangente, não se prendendo somente à tecnologia AlwaysOn mas abordando os demais aspectos deste assunto tão importante, respondendo as várias perguntas dos participantes, onde consegui ganhar o livro SQL Server Transaction Log Management que já tava na minha lista de compras respondendo o que é Recovery Point Objective.

 

Marcus Vinicius

 
 

Por último assisti a sessão do Marcus Vinicius Bittencourt que se virou bem mesmo com a impossibilidade da presença do grande Laerte Jr., falando sobre as comunidades e os principais contadores do Performance Monitor.

 
 
 
 

Francisco SantosDepois tiveram os sorteios e os agradecimentos aos patrocinadores e ao próprio PASS, onde acabei ganhando uma pasta pra notebook bem legal que por acaso eu estava precisando enquanto o Francisco Santos ganhou uma licença full do SQL Toolbelt da Redgate.

 
 
 

Confira a galeria com as fotos do evento:

Sem dúvidas participar dos eventos do PASS é excelente, não deixem de aproveitar participando dos próximos que já estão agendados.

ago 30

Top queries por consumo

Uma situação muito comum é precisar levantar quais são as queries com maior tempo de CPU, I/O ou consumo de páginas em memória.

 

Ajustei este script disponível no próprio BOL pra pegar também as operações de leitura do disco da DMV sys.dm_exec_query_stats fazendo um cross apply com a sys.dm_exec_sql_text pegando o texto das queries e sys.dm_exec_query_plan para pegar o plano:

Basta substituir os comentários para trocar a ordem da lista (maior tempo de CPU, maior leitura de disco, etc.). Veja que estamos pegando as top 10 mas é só ajustar se quiser ver mais:

 

SELECT TOP 10 SUBSTRING(qt.TEXT, (qs.statement_start_offset/2)+1,
((CASE qs.statement_end_offset
WHEN -1 THEN DATALENGTH(qt.TEXT)
ELSE qs.statement_end_offset
END – qs.statement_start_offset)/2)+1),
qs.execution_count,
qs.total_logical_reads as total_leitura_memoria, qs.last_logical_reads as ultima_leitura_memoria,
qs.total_logical_writes as total_escrita_memoria, qs.last_logical_writes as ultima_escrita_memoria,
qs.total_physical_reads as total_leitura_disco, qs.last_physical_reads as ultima_leitura_disco,
qs.total_worker_time as tempo_CPU_total, qs.last_worker_time as ultimo_tempo_CPU,
qs.total_elapsed_time/1000000 as tempo_total_execucao,
qs.last_elapsed_time/1000000 as ultimo_tempo_execucao,
qs.last_execution_time as data_ultima_execucao,
qp.query_plan as plano_execucao
FROM sys.dm_exec_query_stats qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) qt
CROSS APPLY sys.dm_exec_query_plan(qs.plan_handle) qp
ORDER BY qs.total_logical_reads DESC — ordenando por leituras em memória
— ORDER BY qs.total_logical_writes DESC — escritas em memória
— ORDER BY qs.total_worker_time DESC — tempo de CPU
— ORDER BY qs.total_physical_reads DESC — leituras do disco

 

Se eu quisesse ordenar por tempo de CPU, bastaria trocar as linhas:

De
ORDER BY qs.total_logical_reads DESC — ordenando por leituras em memória

Para
— ORDER BY qs.total_logical_reads DESC — ordenando por leituras em memória

 

De
— ORDER BY qs.total_worker_time DESC — tempo de CPU

Para
ORDER BY qs.total_worker_time DESC — tempo de CPU

 

Agora já é possível saber quais são as queries que mais consomem além de documentar o tempo que elas demoram para ser executadas quando tudo está bem ou durante uma análise, quando tudo está mal.

ago 26

SQL Server Editions

São tantos recursos que muitas vezes precisamos pesquisar para saber a diferença entre as edições do SQL como Datacenter, Enterprise, Standard, Web, Workgroup e Express.

Para facilitar a leitura estamos listando as principais diferenças mas se você quiser uma lista completa, neste artigo do Technet Library você encontra todas as diferenças, podendo selecionar a versão entre 2008, 2008 R2 e 2012.

Abaixo temos as diferenças entre as edições do 2008 R2, que ainda possui as edições Datacenter (DC) e Workgroup, retiradas da versão 2012 simplificando bastante a maneira de licenciar o produto.

Esta é uma leitura obrigatória, tanto para evitar equívocos na hora de projetar a arquitetura do ambiente quanto para obter certificações Microsoft, já que os exames 70-450 e 70-451 ainda estão disponíveis (leia aqui).

Observe que sempre digo diferença entre edições, se quiser saber a diferença entre versõeseste blog está sempre atualizado.

 

Escalabilidade e Performance

Feature Name DC Enterprise Standard Web Workgroup Express
Number of CPUs OS maximum 8 4 4 2 1
Maximum memory utilized OS maximum 2 TB 64 GB 64 GB 4 GB 1 GB
Maximum database size 524 PB 524 PB 524 PB 524 PB 524 PB 10 GB
IA64 hardware support Yes Yes
Resource governor Yes Yes
Table and index partitioning Yes Yes
Parallel index operations Yes Yes
Parallel consistency checks (DBCC) Yes Yes
Enhanced read-ahead scan Yes Yes
Scalable shared databases Yes Yes
Direct query of index views using NOEXPAND hint Yes Yes Yes
Automatic indexed view maintenance Yes Yes Yes
Automatic use of indexed views by query optimizer Yes Yes
Distributed Partitioned Views Yes Yes Partial. Distributed Partitioned Views are not updatable Partial. Distributed Partitioned Views are not updatable Partial. Distributed Partitioned Views are not updatable Partial. Distributed Partitioned Views are not updatable

 

 

 

 

Alta Disponibilidade (AlwaysOn)

Feature Name DC Enterprise Standard Web Workgroup Express
Log shipping Yes Yes Yes Yes Yes
Database mirroring2 Yes Yes Yes (single thread, synchronous only) Witness only Witness only Witness only
Automatic corruption recovery from mirror Yes Yes Yes
Log stream compression Yes Yes Yes
Number of Failover clustering nodes Operating system maximum1 Operating system maximum1 2 nodes
Backup compression Yes Yes Yes3
Mirrored backups Yes Yes
Database snapshots Yes Yes
Fast recovery Yes Yes
Online indexing Yes Yes
Online page and file restore Yes Yes
Online configuration of Peer to Peer nodes Yes Yes
Hot add memory and CPU support Yes Yes

1-Windows Server 2003 supports a maximum of 8 failover cluster nodes. Windows Server 2008 supports a maximum of 16 failover cluster nodes.

2-Asynchronous database mirroring is supported only by SQL Server 2005 Enterprise Edition SP1 and later versions.

3-Backup compression for Standard edition of SQL Server is supported only in SQL Server 2008 R2 or higher versions

 

 

 

 

 

Suporte a Virtualização

Feature Name DC Enterprise Standard Web Workgroup Express
Hypervisor support Yes Yes Yes Yes Yes Yes
Guest failover clustering support for virtualization Yes Yes Yes
Hyper-V live migration Yes Yes Yes
Application mobility Yes Yes

 

 

 

 

 

Replicação

Feature Name DC Enterprise Standard Web Workgroup Express
Snapshot replication Yes Yes Yes Subscriber only Yes Subscriber only
Merge replication Yes Yes Yes Subscriber only Restricted¹ Subscriber only
Transactional replication Yes Yes Yes Subscriber only Restricted¹ Subscriber only
SQL Server change tracking Yes Yes Yes Yes Yes Yes
Publishing data from SQL Server to non SQL Server subscribers Yes Yes Yes
Publishing data from Oracle to SQL Server Yes Yes
Peer to Peer replication Yes Yes

 

 

 

 

Segurança

Feature Name DC Enterprise Standard Web Workgroup Express
Windows Integrated Authentication (including Kerberos) Yes Yes Yes Yes Yes Yes
Integration with Microsoft baseline security analyzer Yes Yes Yes Yes Yes Yes
C2 compliant audit mode1 Yes Yes Yes Yes Yes Yes
Common criteria compliance Yes Yes Yes Yes Yes Yes
Data encryption and key management Yes Yes Yes Yes Yes Yes
Module signing Yes Yes Yes Yes Yes Yes
Transport Layer Security channel encryption Yes Yes Yes Yes Yes Yes
Windows password policy support Yes Yes Yes Yes Yes Yes
User-schema separation Yes Yes Yes Yes Yes Yes
Login triggers and connection endpoints Yes Yes Yes Yes Yes Yes
Secure configuration through policy-based management Yes Yes Yes Yes Yes Yes
SQL Server audit (fine-grained auditing) Yes Yes
Transparent database encryption Yes Yes
Extensible key management Yes Yes

1-For a description of this feature see, c2 audit mode Option.

 

 

 

 

Gerenciamento para uma Instância

Feature Name DC Enterprise Standard Web Workgroup Express
Policy-Based Management Yes Yes Yes Yes Yes Yes
PowerShell support Yes Yes Yes Yes Yes Yes
SQL Server Management Object (SMO) Yes Yes Yes Yes Yes Yes
SysPrep support1 Yes Yes Yes Yes Yes Yes
SQL Server connection director Yes Yes Yes Yes Yes Yes
Dedicated admin connection Yes Yes Yes Yes Yes Yes (Under trace flag)
Policy automation (check on schedule and change) Yes Yes Yes Yes Yes
Maintenance plans Yes Yes Yes Yes Yes
Database mail Yes Yes Yes Yes Yes
Performance data collector Yes Yes Yes Yes Yes
System Center Operations Manager Management Pack Yes Yes Yes Yes Yes
Plan guides Yes Yes Yes Yes .
User instances Yes

 

 

 

 

 

Gerenciamento para múltiplas instâncias

Feature Name DC Enterprise Standard Web Workgroup Express
Support for data-tier application (DAC) operations – extract, deploy, upgrade Yes Yes Yes Yes Yes Yes
Able to enroll for multi-instance management. Yes1 Yes2 Yes Yes Yes
Multi-instance dashboard views and drilldowns Yes Yes2
Policy-based resource utilization evaluation Yes Yes2

 

 

 

 

Ferramentas de Gerenciamento

Feature Name DC Enterprise Standard Web Workgroup Express
SQL Server Configuration Manager Yes Yes Yes Yes Yes Yes
SQL CMD (command prompt tool) Yes Yes Yes Yes Yes Yes
SQL Server Migration Assistant1 Yes Yes Yes Yes Yes Yes
SQL Server Management Studio2 Yes Yes Yes Yes Yes
SQL Server Agent Yes Yes Yes Yes Yes
Database Engine Tuning Advisor Yes Yes Yes Yes Yes
SQL Server Profiler Yes Yes Yes Yes Yes No3
Analysis Services, PowerPivot IT operation dashboard Yes Yes

 

 

 

 

 

Ferramentas de Desenvolvimento

Feature Name DC Enterprise Standard Web Workgroup Express
Microsoft Visual Studio Integration Yes Yes Yes Yes Yes Yes
IntelliSense (Transact-SQL and MDX) Yes Yes Yes Yes No
(SSMS is not installed with this edition)
Business Intelligence Development Studio Yes Yes Yes Yes Yes
SQL query, edit and design tools Yes Yes Yes Yes
Version control support Yes Yes Yes Yes
MDX edit, debug, and design tools Yes Yes Yes

 

 

ago 25

Exames 70-450 e 70-451 disponíveis!

Uma boa notícia pra quem não teve tempo para tirar as certificações de SQL Server 2008 é que os exames 70-450 e 70-451 ainda estão disponíveis.

 

Apesar de vermos bastante na internet que estes exames seriam retirados pela Microsoft em 31/07/2013, informação que esteve nas páginas dos exames que também já foram atualizadas, estes exames só serão retirados em 31/01/2014, de acordo com a página de exames marcados para retirada da Microsoft.

 

Portanto, se você ainda pretende se certificar em SQL Server 2008, ainda há tempo. Agende seu exame no site da Prometric, estude e boa sorte.

ago 11

SQL Saturday #245 – Rio de Janeiro

Este evento já aconteceu, clique aqui para ver como foi.

No último sábado de Agosto, 31/08, teremos um dos melhores eventos de SQL Server ,no Rio de Janeiro. Pra quem não conhece, o SQL Saturday é um evento realizado pelo PASS em diversas cidades do mundo, com palestras de diversos níveis, realizadas por profissionais experientes, com níveis de iniciante a avançado. É uma oportunidade de aprender o que outros profissionais se dedicaram para conhecer a fundo, compartilhando suas experiências. É também uma excelente oportunidade se você quer palestrar, pois você aprende como funciona, compara as palestras e pega muitas dicas pra preparar a sua. Devido a magnitude do evento diversos profissionais de toda a parte estarão presentes, o que torna o ambiente propício para um networking de qualidade.

 

Serão 3 salas com palestras simultâneas, que você escolhe de acordo com o nível ou o seu interesse no tema de cada uma. Confira a agenda:

 

Horário Sala 1 Sala 2 Sala 3
8:30 AM SQLSaturday 245 SQLSaturday 245 SQLSaturday 245
Registrations Registrations Registrations
Nível: Não Técnico Nível: Não Técnico Nível: Não Técnico
9:00 AM Erika Madeira Marcos Freccia Vanessa Porto
SQL Server 2014, fique por dentro! Introdução a Queues e Wait Types  Uso do SSIS Catalog na publicação de pacotes no Integration Services 2012
Nível: Intermediário Nível: Iniciante Nível: Intermediário
10:30 AM SQLSatruday 245 SQLSatruday 245 SQLSatruday 245
Intervalo Intervalo Intervalo
Nível: Não Técnico Nível: Não Técnico Nível: Não Técnico
10:45 AM Luan Moreno M. Maciel Gustavo Maia Aguiar Nilton Pinheiro
Hekaton – Um novo paradigma! Concorrência Otimista, Read Committed Snapshot (RCSI) e Snapshot Isolation Level Troubleshooting for Microsoft SQL Server 2005/2008/2012
Nível: Intermediário Nível: Avançado Nível: Avançado
12:15 PM SQLSaturday 245 SQLSaturday 245 SQLSaturday 245
Pausa para almoço Pausa para almoço Pausa para almoço
Nível: Não Técnico Nível: Não Técnico Nível: Não Técnico
1:45 PM Oduvaldo Zeferino SQLSaturday 245 SQLSaturday 245
Estamos preparados para melhorar o desempenho dos bancos de dados? Pausa para almoço Pausa para almoço
Nível: Intermediário Nível: Não Técnico Nível: Não Técnico
2:45 PM Fabiano Neves Amorim Dennes Torres De Oliveira Marcelo Fernandes
SQL Server 2014 – Novidades no Query Optimizer Gerenciando muitos servidores com uso de EPM Implementando soluções de alta disponibilidade para seu ambiente
Nível: Intermediário Nível: Avançado Nível: Intermediário
4:15 PM SQLSatruday 245 SQLSatruday 245 SQLSatruday 245
Intervalo Intervalo Intervalo
Nível: Não Técnico Nível: Não Técnico Nível: Não Técnico
4:30 PM Diego Nogare Marcus Vinícius Bittencourt Leandro Ribeiro
Por onde começar no BigData?? SQL Performance Countes com Powershell Resolvendo problemas de Fragmentação do Transaction Log
Nível: Intermediário Nível: Avançado Nível: Intermediário
6:00 PM SQLSaturday 245 SQLSaturday 245 SQLSaturday 245
Sorteios Sorteios Sorteios
Nível: Não Técnico Nível: Não Técnico Nível: Não Técnico


Não gostei muito da quantidade de intervalos, principalmente pelas palestras que foram enviadas mas ficaram de fora, mas gostei muito dos temas escolhidos e dos palestrantes. Tem Marcos Vinícius Bittencourt com Laerte Junior, Fabiano Neves Amorim, Gustavo Maia Aguiar, Luan Moreno Maciel, Erika Madeira, Nilton Pinheiro, Vanessa Porto, Dennses Torres, Marcos Freccia, Diego Nogare, Marcelo Fernandes, Oduvaldo Zeferino e Leandro Ribeiro.

 

Eu estarei por lá, vou assistir as palestras:

 

SQL Server 2014, fique por dentro!

A cada nova versão do produto, novidades aparecem elevando ainda mais a capacidade da nossa plataforma de banco de dados favorita! Fique por dentro das mudanças e saiba o que esperar do lançamento do SQL Server 2014 com tecnologia in-memory, missão crítica estendida a cenários de nuvem híbrida e insights sendo liberados em tempo real !

Session Level: Intermediate

Erika Madeira

Erika Madeira é graduada em Engenharia da Computação e atuou na área de tecnologia da informação por mais de 3 anos como Administradora de Bando de Dados (DBA). Atualmente, especialista do time de SQL Server da Microsoft, atua com foco na comunidade técnica. Mantêm o blog http://blogs.technet.com/b/sqlserverbrasil/ com artigos relacionados a banco de dados em toda sua abrangência.

Contact URLhttp://blogs.technet.com/b/sqlserverbrasil/

Concorrência Otimista, Read Committed Snapshot (RCSI) e Snapshot Isolation Level

As implementações de modelo de concorrência otimista no SQL Server estão disponíveis desde o SQL Server 2005 e ainda são pouco conhecidas. Aprenda a utilizar com esse modelo de concorrência e entenda suas vantagens, desvantagens bem como alguns efeitos colaterais que precisam ser tratados para que sua aplicação possa tirar proveito desses recursos de concorrência.

Session Level: Advanced

Gustavo Maia Aguiar

Gustavo Maia Aguiar é entusiasta do mundo de armazenamento e atualmente é coordenador de banco de dados e ferramentas analíticas de uma grande instituição financeira e tem trabalhado com os bancos de dados SQL Server, DB2 e Netezza. É profissional MCITP, MCT, MCSE e MVP e participa de várias iniciativas relacionadas à comunidade de SQL Server no Brasil. Tem atuado com SQL Server desde 2002 em atividades de suporte, treinamento e consultoria em ambientes de missão crítica.

Contact URLhttp://gustavomaiaaguiar.wordpress.com

SQL Performance Countes com Powershell

Nesta sessão mostraremos alguns dos principais contadores de performance utilizados para diagnosticar a saúde do seu ambiente. Contadores são utilizados para fornecer informações que podem ajudar a determinar gargalos do sistema e ajustes minuciosos e desempenho do aplicativo. O SQL Server fornece inúmeros contadores que proveem uma visão gráfica de como o sistema está funcionando. Vamos conhecer alguns destes contadores, qual sua importância, valores aconselhados e como gerar todas esta gama de informações através de algumas linhas de comando utilizando PowerShell.

Session Level: Advanced

Marcus Vinícius Bittencourt

MARCUS VINÍCIUS BITTENCOURT, MTAC – Chapter Leader do PASS Chapter SQL Server RS, DBA SQL Server das Lojas Colombo, Bacharel em Sistemas de Informação pela UC, MCTS | SQL Server 2005 e 2008. | A palestra será realizada junto com | LAERTE JUNIOR is a SQL Server specialist and an active member of WW SQL Server and the Windows PowerShell community. He also is a huge Star Wars fan (yes, he has the Darth Vader´s Helmet with the voice changer). He has a passion for DC comics and living the simple l

Contact URLhttp://isqlserver.wordpress.com

Estamos preparados para melhorar o desempenho dos bancos de dados?

Gerenciar o desempenho de bancos de dados é uma atividade que envolve mais do que apenas os aspectos técnicos. Envolve colaboração com Desenvolvedores, DBAs, Infraestrutura, Arquitetos, QAs, e executivos. Isolar problemas, analisar e otimizao o desempenho das bases além de complexo é uma atividade que deve ser tratada com transperência e senso de equipe. Nesta sessão serão exibidos vários recursos para monitorar e administrar o desempenho dos bancos de dados, sob várias perspectivas, como infraestrutura, queries, recursos do ambiente, virtualização e etc.

Session Level: Intermediate

Oduvaldo Zeferino   

Over 35 years of proven success bringing and making available software products for the domestic market. Roles included Manager of Product Management, Manager of IT-Business Line, Pre Sales Manager, Technical Support and Data Center Operations. Consultant of Business for IT solutions, his roles bringing technology products to the market, allows the combination of business perspective with the IT perspective.

Contact URLhttp://www.mainwork.com.br

 

Espero encontrá-los por lá!

ago 08

Priority Boost

 

Vamos ver evidências de que o Priority Boost é um risco a estabilidade e a disponibilidade, inimigo de qualquer SLA. Esta é uma opção bem discutida, tem bastante conteúdo recomendando que seja desabilitada, mas é difícil vermos evidências.

  Vamos ver um caso real e entender como funciona.
 

O Windows possui vários níveis de prioridade, uma forma de privilegiar threads na fila até o processador. Threads com prioridade maior furam a fila, e são classificadas de 0 a 31:

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Depois de habilitar o Priority Boost, de acordo com este artigo do MSDN (em inglês) quando o serviço do SQL for reiniciado chamará a API SetPriorityClass setando HIGH_PRIORITY_CLASS. Este nível de prioridade deve ser definido apenas para processos que realizam tarefas críticas ao Sistema Operacional, resumidamente, deixa o nível de prioridade dos worker threads em 15 que é muito perto do maior nível de prioridade do Sistema Operacional.

Os times de suporte relatam diversos problemas com o Priority Boost habilitado, principalmente em ambientes em Cluster, mas vamos ver um caso real e recente.

É um ambiente composto por Windows Server 2008 R2 Enterprise Service Pack 1, SQL Server Standard, e seu período de maior demanda é durante as cargas de dados, chegando a ultrapassar 120.000 transações por segundo. O nó onde o serviço do SQL Server estava rodando sofreu um unexpected shutdown, vejamos os logs:

 

USER_MODE_HEALTH_MONITOR (9e) 
One or more critical user mode components failed to satisfy a health check. 
Hardware mechanisms such as watchdog timers can detect that basic kernel 
services are not executing. However, resource starvation issues, including 
memory leaks, lock contention, and scheduling priority misconfiguration, 
may block critical user mode components without blocking DPCs or 
draining the nonpaged pool. 
Kernel components can extend watchdog timer functionality to user mode 
by periodically monitoring critical applications. This bugcheck indicates 
that a user mode health check failed in a manner such that graceful 
shutdown is unlikely to succeed. It restores critical services by 
rebooting and/or allowing application failover to other servers. 
Arguments: 
Arg1: fffffa80af4476f0, Process that failed to satisfy a health check within the 
configured timeout 
Arg2: 00000000000004b0, Health monitoring timeout (seconds) 
Arg3: 0000000000000000 
Arg4: 0000000000000000 

 

Log Name: System 
Source: Microsoft-Windows-FailoverClustering 
Date: 28/07/2013 09:02:06 
Event ID: 1230 
Task Category: Resource Control Manager 
Level: Error 
Keywords: 
User: SYSTEM 
Computer: SQL-01.domain,com 
Description: 
Cluster resource ”VIPNAME” (resource type ””, DLL ”clusres.dll”) either crashed or deadlocked. The Resource Hosting Subsystem (RHS) process will now attempt to terminate, and the resource will be marked to run in a separate monitor. 

Veja que uma tarefa importante deixou de ser executada e o próprio log explica o motivo:

 

Hardware mechanisms such as watchdog timers can detect that basic kernel 
services are not executing. However, resource starvation issues, including 
memory leaks, lock contention, and scheduling priority misconfiguration
may block critical user mode components without blocking DPCs or 
draining the nonpaged pool. 

Cluster resource ”VIPNAME” (resource type ””, DLL ”clusres.dll”) either crashed or deadlocked. 

 

Em seguida o servidor sofreu um blue screen e reiniciou.

 

Verifique sempre seu ambiente, Priority Boost é uma opção pra benchmark, pra nerdisse nossa de testes e experimentos, devendo ficar longe de ambientes de produção.

 

 

 

jul 20

MTA – Database Fundamentals

No dia 13/07 conquistei mais uma certificação e compartilho com vocês esta experiência, no intuito de entusiasmar quem quer tirar uma certificação. A certificação MTA – Database Fundamentals testa o conhecimento geral em banco de dados, e não uma solução específica como o SQL Server ou outros sistemas de banco de dados. É obtida através do exame 98-364, fazendo 70 ou mais pontos de 100.

Pra quem tem experiência a prova é tranquila, não exige que se saiba detalhes de sintaxe com pegadinhas faltando uma vírgula, aspas, etc. São questões que realmente devemos saber, conceitos que devemos ter compreendido.

Para se ter uma idéia, quando a avaliação quer testar seus conhecimentos nos comandos SQL, as comparações são feitas entre ALTER TABLE, MODIFY TABLE, CHANGE TABLE, coisas do tipo. Porém, pra quem nunca usa queries em suas atividades diárias, existem questões seletivas questionando como se cria um índice composto, por exemplo. Outras questões avaliam a ordem dos parâmetros na criação de índices, selects e afins.

Apesar de poucas, caíram questões sobre normalização. Pra quem ainda não estudou normalização, abaixo tem um KB da Microsoft sobre o assunto e um excelente artigo do Julio Battisti:

http://support.microsoft.com/kb/283878/pt-br

http://www.juliobattisti.com.br/artigos/office/modelorelacional_p4.asp

Independente da plataforma que você trabalha, esta certificação é uma abordagem geral do conceito de banco de dados e, na minha opinião, faz diferença no currículo, principalmente de quem está começando.

 

Boa sorte!

 

abr 21

Fragmentação das bases

No artigo “Seu job de rebuild demora muito” explicamos a diferença entre os principais tipos de fragmentação das bases do SQL Server, a diferença entre REBUILD e REORGANIZE, o que é FILL FACTOR, além de um script que faz REORGANIZE quando a fragmentação externa é inferior a 30% e REBUILD se for maior. Também explica como alterar este parâmetro caso você queira alterar os 30% para outro valor.

Como muitos ambientes são grandes e não comportam a automatização deste tipo de atividade, neste artigo vamos explicar como levantar e analisar a fragmentação para executá-la quando necessário, podendo definir uma estratégia.

 

Problema

 

Analisar e documentar a fragmentação interna e externa das páginas de dados do SQL Server, detalhando os objetos impactados com informações como nome da tabela, nome do índice, tipo (cluster, heaps, etc.), porcentagem de fragmentação externa, porcentagem de fragmentação interna, quantidade de fragmentos e quantidade de registros do objeto.

 

Solução

 

Encontramos muitos scripts na internet capazes de nos fornecer dados sobre fragmentação das bases, porém, apesar de utilizar a mesma fonte (sys.dm_db_index_physical_stats) a maioria é pobre em informações e não nos permite avaliar corretamente o impacto ou tipo da fragmentação.

O Arshad Ali escreveu este excelente artigo (em inglês) no MSSQL Tips, explicando os tipos de fragmentação, como extrair informações da sys.dm_db_index_physical_stats e como interpretar os resultados. Alterei um pouco seu scritp para atender nossa necessidade, agora vamos ao que interessa.

 

Como utilizar a DMV sys.dm_db_index_physical_stats

 

A sintaxe é bem simples:

 

SELECT * FROM sys.dm_db_index_physical_stats (database_id, object_id, index_id, partition_number, mode) 

 

Os três primeiros parâmetros são intuitivos, ID da base, ID do objeto, ID do índice e número da partição. O último parâmetro define o tipo de retorno que teremos que pode ser LIMITED, SAMPLED ou DETAILED.

Para todos os parâmetros podemos utilizar NULL, aceitando assim seus valores default. Ex:

 

SELECT * FROM sys.dm_db_index_physical_stats (null,null,null,null,null);

 

Se quiser obter informações detalhadas de todas as bases, objetos e índices utilize:

 

SELECT * FROM sys.dm_db_index_physical_stats (null,null,null,null,’DETAILED’);

 

O script

 

Agora que já entendemos de onde partem as informações, vamos ao script. Fiz algumas adaptações para verificar todas as bases exceto do próprio SQL:

  

DECLARE @db_id int;
DECLARE db_cursor CURSOR FOR
SELECT dbid
FROM MASTER.dbo.sysdatabases
WHERE name NOT IN (‘master’,’model’,’msdb’,’tempdb’)

OPEN db_cursor

FETCH NEXT FROM db_cursor INTO @db_id

WHILE @@FETCH_STATUS = 0
BEGIN
select DB_NAME(@db_id) as [Database]
,object_name(IPS.[object_id]) as [TableName]
,SI.index_id as [SI.index_id]
,SI.name AS [IndexName]
,IPS.index_type_desc
,IPS.index_id
,ROUND(IPS.avg_fragmentation_in_percent,2) AS avg_fragmentation_in_percent
,ROUND(IPS.avg_fragmentation_in_percent,2) AS avg_fragmentation_in_percent
,IPS.record_count
,IPS.fragment_count
from sys.dm_db_index_physical_stats(@db_id, null, null, null, ‘detailed’) as IPS
inner join sys.indexes as SI with (nolock) on IPS.[object_id] = SI.[object_id] and IPS.index_id = SI.index_id
inner join sys.tables as ST with (nolock) on IPS.[object_id] = ST.[object_id]
where ST.is_ms_shipped = 0
and IPS.avg_fragmentation_in_percent>=10 
and IPS.page_count>25 
and IPS.index_type_desc<>’heap’ 
and IPS.index_level=0 
order by IPS.avg_fragmentation_in_percent desc

FETCH NEXT FROM db_cursor INTO @db_id
END
CLOSE db_cursor
DEALLOCATE db_cursor

 

Pra quem quer entender o script, estou apenas dando um select na DMV que comentamos acima e relacionando ela com as tabelas de sistema sys.indexes e sys.tables, para obtermos os nomes dos objetos. Na cláusula where temos:

 

is_ms_shipped = para distinguir objetos criados por você dos objetos que já vem no SQL Server;

avg_fragmentation_in_percent > 10 = não queremos saber sobre os objetos contíguos, somente os fragmentados;

page_count > 25 = objetos muito pequenos nem compensa levantar fragmentação. Uma tabela que ocupa duas páginas, por exemplo, se estas não estiverem uma ao lado da outra, já estaria 50% fragmentada. Vamos ver somente objetos com mais de 25 páginas;

index_type_desc <> ‘heap’  = eu geralmente comento esta linha pois se é heap e tem mais de 25 páginas, deveria ao menos ter um índice, então já aproveito este report para levantar essas heaps;

index_level = para o relatório não ficar confuso, vamos analisar o nível onde ficam os dados, já que durante o REBUILD todos os níveis são refeitos;

 

O resultado do script

 

Vamos ver o que este script traz e interpretar os dados:

 

 

Tirando as colunas óbvias como TableName, IndexName, etc., vamos ver o que diz cada coluna:

 

avg_fragmentation_in_percent: diz respeito a fragmentação lógica, ou seja, de todas as páginas do objeto quantas estão fora de ordem, em porcentagem;

avg_page_space_used_in_percent: aqui podemos ver a fragmentação física, o quanto as páginas de dados estão preenchidas com registros. Depois de fazer um REBUILD com o FILL FACTOR em 90%, por exemplo, devemos ver esta coluna com 90% no caso dos índices;

record_count: quantos registros este objeto possui. É uma informação útil pra saber se é um objeto grande, com muitos registros;

fragment_count: suponhamos que você tem um objeto de 30 páginas e as dez primeiras estão contíguas em um bloco, outras dez estão 50 páginas depois e as últimas 10 em um outro bloco de páginas mais adiante. Neste caso teríamos fragment_count igual a 3.

 

Agora, utilizando a linha 1 como exemplo, podemos ver que na tabela tbCustomer, o índice tbCustomer5 é do tipo não cluster, está 98,96% fragmentado, suas páginas estão em média com 59,44% do espaço preenchido, possui 37.882 registros e está espalhado em 288 pedaços pelo arquivo de dados.

 

Veja que o script ordena colocando os mais fragmentados no início, utilizando a coluna avg_fragmentation_in_percent. Eu copio os dados, removo as colunas de ID, formato como tabela e rapidamente tenho uma tabela bonita pra colocar no relatório. Ajustei o script pra já arredondar a fragmentação e o espaço utilizado da página, agora já retorna tipo 96,55% ao invés de vários dígitos:

 

 

Quem gostou ou tem críticas pode comentar, curtir no Facebook, Google+, Tweetar ou postar em qualquer outra rede social.

 

abr 01

2º Encontro de 2013 – SQL Server RS

Será realizado o 2º encontro da comunidade SQL Server RS deste ano, através de um Webcast conduzido pela Ana Paula de Almeida, abordando um assunto que sempre gera dúvidas, principalmente por ter mudado bastante na versão 2012 do SQL Server: LICENCIAMENTO

 

Achei bacana o encontro ser realizado através de um Webcast, assim as pessoas de outras regiões do Brasil (meu caso) poderão participar.

 

O evento será na terça-feira, 09 de Abril de 2013 as 21:00.

 

Para se inscrever basta acessar o link da comunidade clicando aqui (recomendado), ou diretamente pelo site da Microsoft neste outro link.

mar 15

Restaurar uma base em outra base existente

É muito comum em ambientes onde a base de homologação fica no próprio servidor de produção ter que restaurar uma base em cima de outra. Geralmente precisamos fazer um backup da base de produção e restaurar em cima da base de homologação para deixá-la igual e assim tornar os testes válidos.

Exemplo:

Restaurar a base AdventureWorks em cima da base AdventureWorksHmg sem alterar seu nome e o caminho de seus arquivos.

Vamos ver qual o procedimento para atingir este objetivo:

 

1- Se não tivermos um backup atual, precisamos fazer ele agora:

BACKUP DATABASE AdventureWorks TO DISK = ‘C:\Backups\AdventureWorks_UpdateHmg.bak’ –qualquer nome

 

2- Depois temos que descobrir o nome lógico dos arquivos. Este nome lógico é um nome que referencia os arquivos em seu respectivo caminho. Por exemplo, sua base AdventureWorks pode ter dois arquivos, o C:\Databases\AdventureWorks.mdf (dados) e o C:\Databases\AdventureWorks.ldf (Tlogs). Para saber o nome lógico, vamos examinar o arquivo de backup que acabamos de gerar:

 

RESTORE FILELISTONLY FROM DISK = ‘C:\Backups\AdventureWorks_UpdateHmg.bak’

 

Teremos uma série de informações mas as que interessam neste momento são:

 

Reparem que temos AdventureWorks_Data e AdventureWorks_Log, ou seja, os nomes lógicos dos nossos arquivos físicos.

 

3- Antes de fazermos o restore, precisamos deixar a base AdventureWorksHmg em modo Restricted User pois não podemos ter usuários querendo fazer alterações na base enquanto fazemos o restore:

 

ALTER DATABASE AdventureWorksHmg SET RESTRICTED_USER WITH ROLLBACK IMMEDIATE

 

4- Agora vamos fazer o restore em cima da base AdventureWorksHmg que já existe:

 

RESTORE DATABASE AdventureWorksHmg FROM DISK = ‘C:\Backups\AdventureWorks_UpdateHmg.bak’
WITH REPLACE, RECOVERY,
MOVE ‘AdventureWorks_Data’ TO ‘C:\Databases\AdventureWorksHmg.MDF’,
MOVE ‘AdventureWorks_Log’ TO ‘C:\Databases\AdventureWorksHmg.LDF’

 

5- Finalizando, não podemos esquecer de deixar a base disponível para os usuários novamente:

 

ALTER DATABASE AdventureWorksHmg SET MULTI_USER 

 

Agora temos todos os dados da base AdventureWorks dentro da base AdventureWorksHmg.

Posts mais antigos «

» Posts mais novos