Listas de verificação do SQL Server

14

Seguindo minha outra pergunta , gostaria de começar a pensar sobre o que devo examinar diariamente / semanalmente / mensalmente em termos de alertas. Espero poder ver os problemas antes que eles aconteçam (esse é o plano) ...

Até agora, comecei a coletar scripts para o seguinte (sem ordem):

Diariamente

  • Verificar o tempo de atividade do sistema (apenas no caso de eu precisar verificar algo como DBA)
  • Verifique o último backup
  • Verifique os backups do log de transações
  • Verifique o status dos trabalhos SQL
  • Verifique o uso médio da CPU nas últimas 24 horas (ou 1140 minutos)

Semanal

  • Verifique o histórico de backup do MSDB
  • Verifique para ver quando a última vez que o CheckDB foi executado
  • Verifique a fragmentação do índice
  • Verifique as estatísticas do índice (leituras vs gravações etc.)
  • Verificar gargalos de E / S

Por mês

  • Verificar índices ausentes
  • Verifique índices que não são mais usados

Alguma outra sugestão? (Eu sou novo no DBA, portanto, qualquer ajuda / conselho é sempre bem-vinda)

sql-server-2008 sql-server-2005 maintenance Stuart Blackler
fonte

Respostas:

3

  1. Backups

    • Verifique se há e-mails de backup
    • Quanto tempo o backup levou para ser executado (duração do backup do banco de dados)
    • Verifique se todos os bancos de dados estão sendo copiados de acordo com um plano de manutenção

  2. Espaço livre em disco. Observe variações significativas da verificação anterior. Os arquivos de log podem ser afetados drasticamente por trabalhos mensais

  3. Falhas no trabalho. Filtrar atividade do trabalho por falhas

  4. Verificações do sistema. Procure nos logs sql por erros críticos.

    • Logs de aplicativos

  5. atuação

    • Verifique as estatísticas de desempenho em todos os servidores
    • Verifique se os contadores estão na faixa normal em todos os servidores de produção

  6. Conectividade

    • Verifique se o aplicativo do cliente pode obter dados do banco de dados
    • Verifique a velocidade aceitável dos dados de acesso

  7. Replicação. Verifique se cada publicação e distribuidor está sendo executado para cada assinatura

Lista de verificação do DBA do SQL Server

Lista de Verificação DBA de Brad

Lista de verificação do Oracle DBA (talvez útil)

Lista de verificação de gerenciamento de banco de dados DBA do SQL Server

Lista de verificação matinal do DBA

Lista de verificação do DBA do MS SQL Server (muitas listas de verificação)

Lista de verificação do DBA do SQL Server

garik
fonte
4

A única variação que eu sugeriria em sua lista de verificação é substituir a palavra BACKUP por RESTORE. Verificar se os backups concluídos são um bom começo, o que realmente importa é se você pode ou não restaurar a partir deles. Alerta sobre uma falha de backup, automatize uma amostragem aleatória de restaurações para que você saiba que seus backups são bons.

O próximo passo na lista de verificação diária / semanal / mensal é o histórico. Uma verificação nos contadores de desempenho x / y / z não faz sentido sem uma linha de base para comparar hoje com ontem. Sem entender o hoje vs o ontem, é impossível prever o próximo mês.

Mark Storey-Smith
fonte
2

AVISO LEGAL: Não é um DBA do SQL Server

Se possível, convém verificar mensalmente os índices que não estão sendo usados ​​por nenhuma consulta. Isso você definitivamente gostaria de fazer por

  • mesas muito grandes
  • tabelas com muitos índices
  • índices com muitas colunas (3 ou mais)
RolandoMySQLDBA
fonte
4
Apenas certifique-se de que "não está sendo usado" reflete um ciclo de negócios inteiro. Ouvi falar de vários casos em que o DBA decidiu descartar um índice que não era usado há alguns meses, e no dia seguinte o relatório trimestral do CFO leva horas em vez de segundos ... você não pode confiar no index_usage_stats DMVs, especialmente se o servidor for reiniciado periodicamente, então eu só faria isso se você está mantendo suas próprias estatísticas de uso ao longo do tempo ...
Aaron Bertrand
2

Verifique frequentemente o comprimento da fila de E / S quanto a gargalos.

Thomas Stringer
fonte
2

Algo para ajudar a realizá-lo ... A Idera lançou uma ferramenta gratuita para revisar os Trabalhos do SQL Server que já usei algumas vezes. É muito bom para obter uma boa visão geral, embora tenha algumas limitações, pois é gratuito. Vale a pena conferir: http://www.idera.com/Products/Free-Tools/SQL-job-manager/

Algo que eu adicionaria ao lado da segurança da casa ... Um arquivo de rastreamento especificamente para capturar a atividade de logon para contas de usuário. Isso permitirá que você encontre contas inativas facilmente. Depois, também script que monitora quando alguém é adicionado a funções fixas de servidor / banco de dados. Especialmente o sysadmin, se você não for o único a gerenciar o servidor / instância.


fonte
Um arquivo de rastreamento é a melhor maneira de fazer isso?
Thomas Stringer
é a maneira mais fácil de obter informações. A menos que você coloque um gatilho para capturar as informações em uma tabela ou log, talvez. Se você usar o SQL 2008 Policy, o gerenciamento poderá ser usado para essa finalidade.
Um rastreamento pode ser o melhor caminho, @ ShawnMelton. Existe uma maneira de modificar o registro ( sqlservercentral.com/articles/security/sqlserverauditingpart1/… ) para que o SQL Server audite todos os logins (com êxito e falhas). Não sei ao certo qual é o melhor meio, mas sempre fiquei apreensivo por manter um rastro funcionando indefinidamente. Seus pensamentos?
Thomas Stringer
Nunca tive problemas ao executar arquivos de rastreamento em que eles afetavam tanto o desempenho. Habilitando a auditoria C2, embora eu tenha, não gosto de habilitar isso. Os Eventos Estendidos oferecem uma alternativa e devem ser o método preferido para usar arquivos de rastreio, mais potência com eles. Você pode verificar se há uma opção para eventos de login, tenho certeza de que existe. Pelo que entendi sobre eles, eles são de alguma forma excluídos de causar um impacto no desempenho.
legais. Estou inclinado a concordar com você. E sim, C2 é definitivamente uma daquelas situações de apenas usar se você precisar.
Thomas Stringer
0
  • verifique o log de erros do SQL Server e do SQL Server Agent
  • verifique o status dos servidores espelhados (principal e espelho)
  • verificar mudanças no tempo de execução dos trabalhos
  • verifique o nó ativo no servidor sql em cluster
  • verifique o ESPAÇO DO DISCO
Alex_L
fonte