Cuidados Indispensáveis para todo DBA na Manutenção do SQL Server
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:
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
