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
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?
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
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?
No comments:
Post a Comment