Para quem participou do TechEd 2008 e visitou a nossa apresentação gostaria de agradecer a presença.  O Título de nossa apresentação foi  “ Cuidados Indispensáveis para todo DBA na Manutenção do SQL Server ”.

Bom, para que todos tenham em linhas gerais o conhecimento o que foi apresentado vamos mostrar abaixo. Basicamente classificamos 10 itens que são importantes para a manutenção de um servidor SQL Server. São eles :

10. Gerenciamento de arquivos de dados

Pontos importantes para otimizar os arquivos de dados:

  • Desfragmentar fisicamente os discos
  • Efetuar configuração de RAID array
  • Pré-alocar um tamanho inicial razoável (montante mínimo do capacity planning)
  • Não mantenha o auto-grow fora de controle (monitore ! )
  • Habilite o Instant Initialization
  • Desabilite o Auto-Shrink (crie jobs de DBCC Shrink)
  • Quando vários desses pontos irão ajudar também os logs, existe um ponto mais importante ainda que se deve ter atenção na parte dos dados – tabelas e índices
    ·         Fragmentação de Índices (Index fragmentation)


9. Gerenciamento de arquivos de log transacional

        Otimizando os arquivos de Log

  • Alocar somente um arquivo de log
  •  Isolar o arquivo de log em um drive separado (escritas sequenciais) dos dados
  • Desfragmentar o drive no qual o log reside
  • Pré-alocar um tamanho de log apropriado
  • Reduza o uso de auto-growth
  • Otimize o RAID array aonde o arquivo de log reside:
    considere RAID 1+0 em vez de RAID 1, RAID 5 não é  recomendado
  • Tenha certeza em otimizar a fragmentação interna do arquivo existente – reduza VLFs (disk bound system pode experimentar alguma degradação de performance no backup de log)

8. Tempdb

        Otimizando a base de dados Tempdb

  • Tempdb deve estar isolado, veja artigo KB 224071. Portanto, em drive diferente dos arquivos de log e dados.
  • No caso de servidores multi-processados, o Tempdb deve ser criado com múltiplos arquivos
  • Criar 1 para cada CPU física (sem Hyperthreading) ou número de cores.
  • Por exemplo, quad proc com dual core são 8 processadores cores, portanto o tempdb deve ser criado com 8 arquivos de dados  para aliviar o gargalo dos recursos do sistema.
    Com o limite recomendado de 10 arquivos de dados.
  • Para mais informações, veja o whitepaper Working with Tempdb e o artigo KB: 328551

7. Sua estratégia de indexação está funcionando?

        Estratégia de índices

*      Determine testes padrões preliminares do uso da tabela

*      OLTP – poucos índices

*      OLAP – mais e largos índices

*      Criação de chaves clusterizadas

*      Criar constraints – chave primária e chaves alternativas/candidatas

*      Manualmente adicione índices para as colunas Foreign key

*      Capture workload(s) e analise com Database Tuning Advisor (2005)

*      Adicione índices extras para ajudar na performance de SARGs, joins, aggregations

   Melhores Práticas de Indexação

*      Não vá loucamente adicionando índices

*      Somente porque você tem índices em todas as colunas (e/ou INCLUA todas colunas) – não significa que você pode !

*      Pare de indexar após você ter configurado a estrutura básica da tabela e comece avaliar aonde quer ir ...

*      Inexação exagerada pode ser pior que pouca indexação

*      Índices que não possuem manutenção podem ser mais problemáticos em longa execução  ( configurar manutenção )

*      Lembre-se, um índice pequeno pode ter pouco uso…

*      Um índice mais largo tem muito mais uso - você pode estar apto para fazer alguns índices existentes mais úteis deixando eles mais largos
(ok, você não pode diretamente adicionar colunas mas você pode criar novos índices e então eliminar aqueles que você não está usando).

6. Estatísticas

        O que ocorre se os dados mudam?

*      Atualização automática

*      Caso o auto update statistics está ON (para ambos o DB e o índice não foram criados com “norecompute”)

*      Caso o percentual de dados mudar

*      Detalhes completos no whitepaper do TechNet

*      Atualização das estatísticas manualmente

*      Para tabelas altamente voláteis aonde a distribuição não é significamente alterada e você verifica vários eventos de “estatísticas”

*      Desative “auto update” ou desative auto update através do acréscimo de STATISTICS_NORECOMPUTE na definição do índice ( melhor controle)

*      Execute UPDATE STATISTICS

 

5. Fragmentação de Índices

Identificando Fragmentação

*     As chaves para um sucesso são:

*      Conhecer quais índices procurar

*      Quais são usados para um range scans?

*      Quais possuem densidade de página muito baixa ?

*      Conhecer quais opções usar nos vários métodos

*      Conhecer como interpretar os resultados

*      Utilizar  sys.dm_db_index_physical_stats DMV em 2005

*      Utilizar DBCC SHOWCONTIG em 2000

*      Continua na versão 2005, mas está obsoleto

*      Simplesmente não reconstrua todos os índices diariamente!

 

4. Identificando corrupção

        DBCC CHECKDB

*      A única maneira de ler todas as páginas alocadas na base de dados

*      Utiliza o force page checksums para ser avaliado (marcado)

*      Escolha entre full checks e WITH PHYSICAL_ONLY

*      Vários algoritmos para minimizar runtime  e executar ONLINE

*      Comparado com 6.5 ou 7.0

*      Novas features em 2005

*      Progress reporting, data purity, indexed views, last known good, no false failures…

 

3. Notificação de Problema

        Como Dizer Algo que Vem Errado ?

*      Você configurou um job regular para executar um DBCC CHECKDB – como você pode dizer se foi errado ?

*      Existem alguns tipos de monitoramente caso contrário você nunca vai saber!

*       Monitoração manual é tempo de consumo e pode ser esquecido em algum momento

*      Solução: Alertas de agentes

*      Crie alertas para :

*      Erro de Severidade 19 e superiores

*      Qualquer erro definido por usuário (ex. Mostrar que o job do CHECKDB  ‘falhou’)

*      Qualquer coisa que esteja interessado

*      Escolha entre NET SEND (unreliable), email, pager

 

2. Fazendo backups

        Utilize Backups

*      Melhor maneira de evitar perca de dados (e talvez downtime)

*      Várias opções disponíveis no SQL Server 2005

*      Backup Full das bases de dados é um bom ponto de partida

*      Série de Backups de log transacional são muito melhores

*      Você deve ter backups para estar apto para usar-los

*      Você deve ter backups válidos para estar apto para usar-los

*      Tenha certeza que as bases de dados estão limpas antes do backup.

*      Tenha certeza que os arquivos de backup não estejam corrompidos.

 

1 . Testando

                É  Tudo Sobre Testar

*      Teste seu:

*      Plano de disaster recovery

*      Se os Backups são válidos

*      Estratégia de Indexação

*      Alertas

*      Teste, teste, teste

*      E então teste novamente dentro de alguns mêses.

*      E novamente.

*      Nós mencionamentos testar ? J