La salud de un servidor es muy importante, nunca se deben resolver estos problemas solo incrementando la potencia del servidor, es muy importante que los sistemas se consideren como un todo.
Cuando un sistema tiene problemas de rendimiento, se debe observar ¿ Que elemento tiene el problema ? pero también se debe localizar ¿ Cual es el elemento que es el que causa el problema?
Existen stores procedures que reportan información de la base de datos, monitores de rendimiento que muestran el estado de un servidor, o de un componente, todo esto debemos saber interpretarlo, por que nos permite generar mejores sistemas.
Un verdadero arquitecto no solo es responsable de sus programadores, es responsable de ese todo que forma el negocio, el arquitecto de sistemas es un director de orquesta, y como tal debe hacer funcionar ese todo
sp_monitor es uno de esos stores, este nos muestra el estado actual de nuestro servidor de SQL
¿Que información nos entrega?
last_run: Fecha en que el proceso fue ejecutado por ultima vez, es importante por que establece el punto desde el que se recolectaron los ultimos datos.
current_run: Fecha actual de ejecucion
seconds: Tiempo en que se tardo en recabar la informacion
cpu_busy: Numero de segundos que el CPU ha estado ocupado por el servidor de SQL
io_Busy: Numero de segundos que el servidor ha dedicado a procesos de entrada y salida
ide: Numero de segundos que el servidor ha estado ocupado
packets_received: Cantidad de paquetes recibidos
packets_sent: Cantidad de paquetes enviados
total_read: Numero de lecturas hechas por SQL Server
total_write: Numero de escrituras a SQL server
total_errors: Cantidad de errores que ocurrieron durante la lectura y escritura
connections: Cantidad de conexiones aceptadas por el servidor de SQL
Para que estos valores tengan sentido, es muy importante que se tome el tiempo que ha transcurrido entre la ejecución anterior y la ejecución actual del proceso, ademas de que es necesario siempre tener los valores de la ejecución anterior para tener valores de referencia
Felices lineas
Cuando un sistema tiene problemas de rendimiento, se debe observar ¿ Que elemento tiene el problema ? pero también se debe localizar ¿ Cual es el elemento que es el que causa el problema?
Existen stores procedures que reportan información de la base de datos, monitores de rendimiento que muestran el estado de un servidor, o de un componente, todo esto debemos saber interpretarlo, por que nos permite generar mejores sistemas.
Un verdadero arquitecto no solo es responsable de sus programadores, es responsable de ese todo que forma el negocio, el arquitecto de sistemas es un director de orquesta, y como tal debe hacer funcionar ese todo
sp_monitor es uno de esos stores, este nos muestra el estado actual de nuestro servidor de SQL
¿Que información nos entrega?
last_run: Fecha en que el proceso fue ejecutado por ultima vez, es importante por que establece el punto desde el que se recolectaron los ultimos datos.
current_run: Fecha actual de ejecucion
seconds: Tiempo en que se tardo en recabar la informacion
cpu_busy: Numero de segundos que el CPU ha estado ocupado por el servidor de SQL
io_Busy: Numero de segundos que el servidor ha dedicado a procesos de entrada y salida
ide: Numero de segundos que el servidor ha estado ocupado
packets_received: Cantidad de paquetes recibidos
packets_sent: Cantidad de paquetes enviados
total_read: Numero de lecturas hechas por SQL Server
total_write: Numero de escrituras a SQL server
total_errors: Cantidad de errores que ocurrieron durante la lectura y escritura
connections: Cantidad de conexiones aceptadas por el servidor de SQL
Para que estos valores tengan sentido, es muy importante que se tome el tiempo que ha transcurrido entre la ejecución anterior y la ejecución actual del proceso, ademas de que es necesario siempre tener los valores de la ejecución anterior para tener valores de referencia
Felices lineas
No hay comentarios.:
Publicar un comentario