Dica rápida: SET STATISTICS IO Vs. SET STATISTICS TIME

Boa tarde!!

O fim do mês tem sido sinónimo de muito trabalho ultimamente, então vou deixar uma dica rápida que vai ajudar no trooubleshooting de queries.

Existem duas opções que podem ser activadas antes da execução de um query, e que devolvem informações úteis para quem está focado na melhoria de performance.

As opções são as seguintes:

  • SET STATISTICS IO ON
    • Devolve informação referente a actividade do disco.
    • Exemplo de outputTable ‘ProductCostHistory’. Scan count 1, logical reads 5, physical
      reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
  • SET STATISTICS TIME ON
    • Devolve informação relativa ao tempo necessário para efectuar o parse, a compilação e executar cada statement.
    • Exemplo de output SQL Server parse and compile time:
      CPU time = 0 ms, elapsed time = 1 ms.
      SQL Server parse and compile time:
      CPU time = 0 ms, elapsed time = 1 ms.

Até a próxima!

Script – Page Restore

Restaurar bases de dados após um desastre não é uma coisa que sonhamos em fazer muitas vezes… Mas quando o problema acontece, temos que agir rápido!

Por este motivo, disponibilizo para download um script que gera o comando de restore do Full Backup, baseado nas páginas que estão presentes na tabela “suspect_pages”.

Como utilizar?
Altere o valor da variável “vBackupPath” e o nome da base de dados na clausula where, no exemplo abaixo é “AdventureWorks2012“.

Com este script, um comando de restore será gerado. Basta copiar, colar e executar.
Atenção: Após a execução deste script será necessário o restore de todos os backups de t-log, até a BD ficar consistente.
Atenção 2: Não execute restore de páginas sem experiência prévia. A probabilidade de problemas pode ser grande. Faça alguns testes com uma DB não produtiva primeiro.
Faça download do scrip aqui. E tenha muito cuidado :)

Verificação de Integridade – Uma rotina necessária.

Hoje irei abordar o tema da verificação de integridade no SQL Server, ou simplesmente sobre o famoso CheckDB. 
O comando CheckDB é um Database Console Command, ou simplesmente DBCC, categorizado como um DBCC de verificação. Este comando é a única maneira de se ler todas as páginas de uma base de dados, sendo a sua execução muito custosa a nível de CPU, Memória e I/O. Vale ressaltar que no SQL Server Enterprise Edition, este comando é executado em múltiplas threads, o que faz a sua execução ser mais rápida.
Como o CheckDB é executado
Pouca gente tem essa curiosidade, mas o CheckDb não corre directamente na base de dados. É criado um snapshot da base de dados, que fica escondido, e as verificações correm sobre este snapshot.
Normalmente as pessoas só percebem isso quando o CheckDB falha, e ao verem a mensagem, percebem que um tal snapshot não pôde ser criado.
A propósito, no caso de haver um erro como este, temos duas opções:
  1. Criar um processo em que é criado um snapshot manualmente com posterior execução do CheckDB sobre este snapshot.
  2. Executar o CheckDB com a opção TABLOCK. Porém, isso poderá trazer problemas já que a BD será alvo de locks por parte do CHECKDB.
Onde quando executar?
Recomenda-se que o CheckDB seja executa no mínimo uma vez por semana. Este procedimento é necessário em todas as DBs, incluindo as system databases e DBs em read-only.

Alguns factos interessantes:

  • Os planos de manutenção do SQL Server ignoram a TempDB…Porém, se a TempDB for corrompida, a instância irá parar! Atenção a esta situação.
  • Ao se executar o CheckDB na master, estaremos a verificar a base de dados (escondida) Resource.

Qual o objectivo do CheckDB?
O CheckDb tem duas funções, a principal é a detecção de inconsistência, e a segunda a correcção das mesmas. Atenção que esta comando verifica a consistência da estrutura da base de dados, não dos dados.
Detecção de inconsistências
O comando CheckDB segue alguns passos na sua execução, passando pelas seguintes fases:
  • Verificação das estruturas alocadas, como GAM, SGAM, PFS, IAM.
  • Verificação de consistência de tabelas e todos os seus índices, assegurando que as páginas de uma tabelas podem ser lidas e tem uma estrutura válida.
  • Verificação dos catálogos de sistema.
Correcção de inconsistências
Após a sua execução, teremos informação sobre a presença de possíveis páginas corrompidas, o que o   próprio CheckDB pode “corrigir”. 
O CheckDB tem uma opção que permite a correcção da estrutura da base de dados, porém os dados existentes nest página serão perdidos. Esta opção é a “REPAIR_ALLOW_DATA_LOSS“, e basicamente a pagina corrompida é deixada de lado, enquanto uma nova página introduzida no seu lugar. Assim, a estrutura ficará consistente, mas os dados contos nesta página serão perdidos. Após a execução deste comando, uma verificação baseada em backups antigos deverá ser feita, de forma a se identificar os dados perdidos e recupera-los.
Outra opção para correcção de inconsistência é a “REPAIR_REBUILD“, que é utilizada para correcção de nonclustered indexes. Neste caso não há perca de dados.
Apesar de haverem opções para correcção, o CheckDB tem as seguintes limitações:
  • Páginas PFS, tabelas de sistema e erros detectados na utilização da opção data purity não podem ser reparados com o CheckDB.
  • Para execução de um comando de repair, a base de dados deverá estar em modo SINGLE_USER.
Opções de execução
Falando sobre opções, temos as seguintes opções na execução do CheckDB:
  • NO_INFOMSGS: Evita o output the mensagens informativas.
  • ALL_ERRORMSDGS: Permite o output de todas as mensagens de erro.
    • Comportamento padrão desde o SQL Server 2008 SP1.
  • NOINDEX: Não verifica os nonclusterd indexes.
  • DATA_PURITY: Valida os dados conforme o tipo de dados da coluna em que está contido.
    • Comportamento padrão desde o SQL Server 2005.
  • ESTIMATEONLY: Estima o valor a ser utilizado pela TempDB.
    • Segundo o Paul Randal, esta opção não esta funcionando correctamente nas versões actuais.
  • TABLOCK: Utiliza locks ao invés de criar um snapshot.
    • Útil quando há problemas na criação do snapshot.
  • EXTENDED_LOGICAL_CHECKS: validação extra em colunas XML e índices Spatial.
  • PHYSICAL_ONLY: Salta a maioria das verificações lógicas.
    • Utiliza muito menos recursos, mas uma execução “full” deverá ser feita constantemente, por razões obvias.

Outras Considerações
Sendo o CheckDB um processo que utiliza muitos recursos, em alguns casos pode demorar muito tempo para ser executado, é frequente não termos tempo para executa-lo dentro da janela de manutenção. Para dar a volta a este problema, recomenda-se que cada passo (interno) dado pelo CheckDB seja executado de forma isolada. Isso pode ser feito ao se executar os seguintes comandos: 
  • CHECKALLOC
  • CHECKTABLE
  • CHECKCATALOG
  • CHECKFILEGROUP
Executando cada dia um destes comandos, conseguimos garantir uma verificação completa, mas de forma faseada.

Outra boa abordagem é a utilização da opção “WITH CHECKSUM” nos backups, isso nos permitirá a validação dos checksums das páginas de uma DB, além da possibilidade de se efectuar um restore com a opção “VERIFY ONLY”. Este método é útil, mas não substitui o CheckDB.

Bem, eu tento sempre escrever o mínimo possível, mas sai o que sai… Espero que este post tenha sigo útil!! Qualquer coisa, estou disponível!!

Até a próxima!!