Recomendaciones de tareas de mantenimiento para SQL Server

Zuljin dijo:

Tengo el siguiente problema:

Un proceso puntual de un sistema se demora más que la cresta, 3 horas aproximadamente. Este proceso se detona con una aplicación cliente - servidor, lo que en palabras mutantes significa que el usuario tiene una aplicación en su computador que se conecta a un servidor con la base de datos SQL Server en una máquina virtual de plataforma VMware.

El análisis rápido dice que el proceso no estresa al servidor de base de datos (no anda corto de CPU ni de memoria ni apurado con IO) así que por ese lado no me preocupo. Mi hipótesis es que hay mucho tráfico de red: el proceso consiste en un algoritmo de ir y venir desde el computador con la aplicación hacia el servidor SQL Server por cada iteración (que son muchas) y como los puntos están distantes (computador personal y servidor sql server) ese tiempo suma mucho, así que para descartar eso voy a meter la aplicación en una máquina virtual en el mismo host vmware en donde reside el SQL Server.

Como dato, la base de datos en cuestión es chiquita, unos 3 gigas de datos.

Peeeeeerooooo otra cosa que creo es que no he realizado suficientes tareas de mantenimiento a las bases de datos SQL Server. Y con tareas de mantenimiento no me refiero a aplicarle los parches de seguridad (que si lo hago una vez al mes) sino que a calcular estadísticas y hueas así. Yo vengo del mundo oracle en donde se realizan tareas de mantenimiento como actualizar periódicamente las estadísticas de los objetos (por ejemplo) y lo mismo estoy haciendo con SQL Server pero puede que me esté faltando algo. Con el tamaño de mierda que tiene la base de datos dudo de que la causa raíz del la lentitud sea algo que se pueda resolver con algún tipo de mantenimiento, pero igual quiero descartar.

¿Ustedes realizan tareas de mantenimiento en sus bases de datos SQL Server? ¿Qué tipo de mantenimiento? Estoy googleando pero me gustaría conocer experiencias de primera mano.

Haz clic para expandir...

Marque en negritas tu problema , supon 20 ms por operacion y que sean 30000 operaciones....... ya tenis 10 minutos MINIMO. Nuestro codigo legacy tiene un problema similar y es imposible de arreglar la ensalada de codigo, el proceso asociado tarda una hora en total. Por lo mismo se esta desarrollando un codigo nuevo bien echo que tarda unos 5-10 minutos en total.

Soujiro dijo:

Marque en negritas tu problema , supon 20 ms por operacion y que sean 30000 operaciones....... ya tenis 10 minutos MINIMO. Nuestro codigo legacy tiene un problema similar y es imposible de arreglar la ensalada de codigo, el proceso asociado tarda una hora en total. Por lo mismo se esta desarrollando un codigo nuevo bien echo que tarda unos 5-10 minutos en total.

Haz clic para expandir...

Algo parecido nos pasó en tiempos del sistema Multivía y se resolvió con meter todo a procedimiento almacenado. El workarround de acercar la aplicación al sql server al meterla a una máquina virtual aunque el ir y venir por red se mantiene, más cerca pero se mantiene.


Estoy viendo por ahí unos índices fragmentados que voy a arreglar una vez que termine la prueba de la aplicación residente en la máquina virtual.

PUAJ que asco, el SQL server no es para "programar", si te vez obligado a hacerlo para solucionar algo es que tu codigo es un bodrio.

Soujiro dijo:

PUAJ que asco, el SQL server no es para "programar", si te vez obligado a hacerlo para solucionar algo es que tu codigo es un bodrio.

Haz clic para expandir...

Lo de multivía era Oracle y ojo, que los procedimientos almacenados son una solución muy buena y robusta.

Zuljin dijo:

Lo de multivía era Oracle y ojo, que los procedimientos almacenados son una solución muy buena y robusta.

Haz clic para expandir...

no, no, a bajo volumen sí, pero mejor delega a una aplicación programada eso, la bd solo debería almacenar, mantenerla, ya es trabajo de otro(equipo), además así es más mantenible y escalable

Tienes que ver el reporte de latencia y tiempo de ejecución, seguro que la app hace la pega muy mal para tardar eso.

xUnk dijo:

no, no, a bajo volumen sí, pero mejor delega a una aplicación programada eso, la bd solo debería almacenar, mantenerla, ya es trabajo de otro(equipo), además así es más mantenible y escalable

Haz clic para expandir...

Es un poco off topic pero sigue siendo una buena charla técnica:

En tiempos de multivía lo que había era un Borland Application Server (java) contra una base de datos Oracle 10g, todo en un datacenter.

El proceso lo que hacía era tomar una entrada de datos, hacer operaciones simples contra la base de datos (selects, tomar decisiones sencillas, updates que suman, etc). Cada operación era un ida y vuelta desde el app server a la base de datos.

Cuando comenzó el sistema la base de datos no tenía movimientos así que la primera carga masiva (sus dos millones de registros) pasó en buen tiempo (una hora aprox), pero cada carga diaria aumentaba el tiempo exponencialmente (2 horas, 4 horas, 8 horas, etc). Llegó un momento en que el proceso de cargar los movimientos diarios del metro se demoraba dos días.
Obviamente los que veíamos la base de datos estábamos vueltos locos con la huea porque los desarrolladores decía que era culpa de la base de datos, pero todo estaba bien indexado, buenos planes, estadísticas, etc.


Finalmente se hizo una reingeniería del proceso y toda la operación "sencilla" de los datos se metió dentro de un procedimiento almacenado residente en Oracle. Básicamente el application server tomaba los datos de cada movimiento de la tarjeta multivía y con los valores iniciales llamaba al procedimiento almacenado que hacía lo mismo que antes estaba en el application server: selects, tomar decisiones sencillas, updates que suman, etc, pero la diferencia es que nunca salía de la base de datos así que no había costo de red. Finalmente el procedimiento almadenado le devuelte una respuesta al servidor de aplicaciones para que éste continuara con su trabajo.


El proceso diario pasó de demorar dos días a demorarse una hora con la ventaja además de que era hora era constante en el tiempo, no aumentaba según fuera el crecimiento de la base de datos. Ese modelo de usar procedimientos almacenados se mantuvo hasta hoy con la carga de archivos en el transantiago.

Evidentemente tiene un contra y es que el proceso quedó customizado para oracle pero da igual porque todos estos sistemas culiaos grandes nunca son portables.

Cosme dijo:

Tienes que ver el reporte de latencia y tiempo de ejecución, seguro que la app hace la pega muy mal para tardar eso.

Haz clic para expandir...

Ahí estoy viendo la huea. Es el típico incidente en que el desarrollador le echa la culpa al administrador de plataforma porque "en mi entorno de desarrollo anda bien".

Zuljin dijo:

El proceso lo que hacía era tomar una entrada de datos, hacer operaciones simples contra la base de datos (selects, tomar decisiones sencillas, updates que suman, etc). Cada operación era un ida y vuelta desde el app server a la base de datos.

Haz clic para expandir...

Reitero es el mismo problema, lo que los desarrolladores no tomaron en cuenta es el VOLUMEN de datos y/o operaciones... "pero si funciona en mi local sin dramas" claro pero en tu local cuantas operaciones realizas 100? 500? 1000? ¿Cuantas realizas en produccion? si son 1000 y probaste 500 operaciones cuando desarrollaste tu código la raja no debería haber niun problema pero sin son 15000 o mas.... tenis una bomba en progreso.

Para estos casos de procesamiento de muchos datos no puede hacerse registro por registro, es demasiado lento. debe hacerse en batchs de 500, 1000, 5000 registros o mas grandes (si es que te aguanta la aplicacion)

Reitero si tenis que usar procedimientos almacenados es para solucionar un problema es que tu codigo es basura. Los procedimientos almacenados deben ser cosas sencillas (KISS) sino algo esta muy muy mal.

Soujiro dijo:

Reitero es el mismo problema, lo que los desarrolladores no tomaron en cuenta es el VOLUMEN de datos y/o operaciones... "pero si funciona en mi local sin dramas" claro pero en tu local cuantas operaciones realizas 100? 500? 1000? ¿Cuantas realizas en produccion? si son 1000 y probaste 500 operaciones cuando desarrollaste tu código la raja no debería haber niun problema pero sin son 15000 o mas.... tenis una bomba en progreso.

Para estos casos de procesamiento de muchos datos no puede hacerse registro por registro, es demasiado lento. debe hacerse en batchs de 500, 1000, 5000 registros o mas grandes (si es que te aguanta la aplicacion)

Reitero si tenis que usar procedimientos almacenados es para solucionar un problema es que tu codigo es basura. Los procedimientos almacenados deben ser cosas sencillas (KISS) sino algo esta muy muy mal.

Haz clic para expandir...

y si, eran cosas sencillas. Simplemente sacaron de la red las operaciones simples y los metieron dentro de la base de datos, lo cual es justamente la razón de ser de los procedimientos almacenados.

@Zuljin , no se si llego tarde, pero sobre que motor de sql estan trabajando? si es 2016 para arriba, tienes activado query store??eso es un buen punto para detectar los problemas de performance, porque así puedes revisar el plan de ejecución que realiza la consulta, e incluso te indica si necesitas indices para mejorar el performance. Lo otro es ver si hay defragmentacion, si lo necesitas, tengo un query que revisa la fragmentacion, por si lo necesitas.

fercas dijo:

@Zuljin , no se si llego tarde, pero sobre que motor de sql estan trabajando? si es 2016 para arriba, tienes activado query store??eso es un buen punto para detectar los problemas de performance, porque así puedes revisar el plan de ejecución que realiza la consulta, e incluso te indica si necesitas indices para mejorar el performance. Lo otro es ver si hay defragmentacion, si lo necesitas, tengo un query que revisa la fragmentacion, por si lo necesitas.

Haz clic para expandir...

Es un 2012, aunque estamos proyectando subirlo.

Al final el proveedor rehizo el código, metió unos índices y el proceso bajó el tiempo a menos de la mitad.