Recientemente hemos trabajado con un cliente para solucionar problemas con una instancia de SQL Server. El cliente ejecutaba SQL Server 2012 en una máquina virtual. Las aplicaciones que se ejecutaban en SQL ServerSQL Server se estaban ejecutando en problemas y el cliente no estaba seguro de cuál era la causa raíz de los problemas.
Inicialmente, configuramos la supervisión de aplicaciones web con el cliente para enviar alertas si la aplicación web comenzó a ejecutarse más lento de lo normal, lo que nos permite saber la próxima vez que se encontró un problema. Al establecer un umbral de tiempo de espera para la velocidad de carga de la página, pudimos identificar diferentes períodos de tiempo en los que el sistema parecía tener un problema al acceder a los datos desde el servidor SQL. Usando las alertas incorporadas, recibimos correos electrónicos tan pronto como se detectó un problema.
A continuación, queríamos configurar la supervisión de SQL Server, por lo que ayudamos al cliente a instalar el agente DeMetricsView para recopilar datos del contador de rendimiento de Windows desde el servidor SQL. Una vez que el agente de MetricsView se instaló correctamente, pudimos recopilar los datos notificados por los contadores de rendimiento de Windows, incluido el uso de SQL Server, la utilización del procesador, el uso del ancho de banda, la asignación de memoria y la disponibilidad del espacio en disco duro.
A medida que supervisamos todas estas métricas, configuramos umbrales máximos y mínimos para cada conjunto de datos para que se nos avise si alguna de las métricas críticas superalos a los límites esperados. Lo que encontramos casi inmediatamente fue que no era, de hecho, un problema SQL en absoluto, sino un problema simple con la forma en que se creó el servidor virtual y los discos duros se particionaron.
Este cliente en particular había creado dos particiones en la unidad, la primera para simplemente el sistema operativo y la segunda unidad era para el almacenamiento de datos. Lo que encontramos rápidamente fue que la unidad del sistema operativo todavía tenía algunos registros SQL en ella que realmente deberían haberse almacenado en la unidad de datos, y los registros SQL estaban causando que la unidad golpeara su capacidad. El usuario tenía varias opciones para resolver este problema. Podrían aumentar la partición de la unidad virtual, dependiendo de si se configuró como una unidad dinámica, o podrían cambiar la configuración de su servidor sql para almacenar los registros en la unidad de datos, así como configurar el truncamiento automático de los registros después de un período de tiempo especificado.
El hecho de que pudiéramos utilizar múltiples componentes del conjunto de herramientas Dotcom-Monitor para ayudar al cliente a identificar el problema habla mucho sobre la capacidad de Dotcom-Monitor para ir más allá de la simple supervisión del tiempo de actividad/tiempo de inactividad que comenzamos a realizar hace más de 15 años. Las herramientas han evolucionado realmente para contener herramientas de solución de problemas y guías de ajuste de rendimiento que le ayudan a obtener una visión completa de 360 grados del rendimiento de su infraestructura y cómo afecta a sus sitios web y aplicaciones web.
Regístrese ahora para una prueba gratuita de 30 días para monitorear aplicaciones web y sitios web,desde el hardware a través de la red hasta la capacidad de respuesta real de los servidores SQL y cada carga de página desde docenas de ubicaciones de todo el mundo.
