Recentemente trabalhamos com um cliente para solucionar problemas com uma instância do SQL Server. O cliente estava executando o SQL Server 2012 em uma Máquina Virtual. Os aplicativos em execução no SQL Server estavam se desemobilizando e o cliente não tinha certeza qual era a causa principal dos problemas.
Inicialmente, configuramos o monitoramento do aplicativo web com o cliente para enviar alertas se o aplicativo web começasse a funcionar mais devagar do que o normal, informando assim na próxima vez que um problema fosse encontrado. Ao definir um limite de tempo limite para a velocidade de carga da página, conseguimos identificar diferentes períodos de tempo onde o sistema parecia ter um problema de acesso aos dados do servidor SQL. Usando os alertas incorporados, recebemos e-mails assim que um problema foi detectado.
Em seguida, queríamos configurar o monitoramento do SQL Server, então ajudamos o cliente a instalar o MetricsView Agent para coletar dados do Contador de Desempenho do Windows do servidor SQL. Uma vez que o MetricsView Agent foi instalado com sucesso, pudemos coletar todos os dados que são relatados pelos Contadores de Desempenho do Windows, incluindo uso do SQL Server, utilização do processador, uso de largura de banda, alocação de memória e disponibilidade de espaço em disco rígido.
À medida que monitoramos todas essas métricas, estabelecemos limites máximos e mínimos para cada conjunto de dados para que pudéssemos ser alertados se alguma das métricas críticas excedesse os limites esperados. O que descobrimos quase imediatamente foi que não era, de fato, um problema SQL, mas um problema simples com a forma como o servidor virtual foi criado e os discos rígidos foram particionados.
Este cliente em particular havia criado duas partições na unidade, a primeira para simplesmente o sistema operacional e a segunda unidade era para armazenamento de dados. O que descobrimos rapidamente foi que a unidade do SO ainda tinha alguns registros SQL nele que realmente deveriam ter sido armazenados na unidade de dados, e os registros SQL estavam fazendo com que a unidade atingisse sua capacidade. O usuário tinha várias opções para resolver esse problema. Eles poderiam aumentar a partição da unidade virtual, dependendo se ela foi configurada como uma unidade dinâmica, ou poderiam alterar as configurações do servidor sql para armazenar os registros na unidade de dados, bem como configurar a truncação automática dos logs após um período de tempo especificado.
O fato de termos sido capazes de utilizar vários componentes do conjunto de ferramentas Dotcom-Monitor para ajudar o cliente a identificar o problema fala muito sobre a capacidade do Dotcom-Monitor de ir além do simples monitoramento de tempo de atividade/inatividade que começamos a realizar há mais de 15 anos. As ferramentas evoluíram verdadeiramente para conter ferramentas de solução de problemas e guias de ajuste de desempenho que ajudam você a obter uma visão completa de 360 graus de como sua infraestrutura está se saindo e como afeta seus sites e aplicativos web.
Inscreva-se agora para uma avaliação gratuita de 30 dias para monitorar aplicativos web e sites,desde o hardware até a rede até a resposta real dos servidores SQL e cada carga de página de dezenas de locais ao redor do mundo.
