none
Se queda atascado en una consulta sql server express 2014

    Pregunta

  • Hola expertos, 

    Soy el responsable de una aplicación en Visual Foxpro que se alimenta de una base de datos sql server express 2014. Esta tarde al llegar al trabajo me comentan que el programa se queda atascado en un proceso, teniendo que terminarlo con ctrl+alt+sup porque no responde. 

    Lo primero que he pensado es en los indices, ya que aunque se hace una reidexación semanal de la tabla principal del programa que contiene 1.300.000 registros es la principal causa de ralentización. Compruebo el nivel de fragmentación y veo que solo está al 12%, aun así reindexo todos sus indices. El problema persiste. Reindexo también todos los indices de las 5 siguientes tablas por tamaño (aunque dichas tablas son comparativamente muchísimo mas pequeñas). El problema persiste. 

    Por último hago una copia de seguridad de la base de datos de producción a mi entorno de desarrollo y donde se quedaba atascado ahora funciona perfectamente. 

    Con lo cual saco a todo el mundo del programa, vuelvo a hacer una copia de seguridad de producción y la restauro sobre si misma... y el problema desaparece.

    Así que no tengo explicación de que puede haber pasado. Y aquí me encuentro preguntado. Mis conocimientos de sql server son a nivel usuario/programador y de haberme pegado con indices y copias de seguridad muchas veces y poco más. Lo único que se me ocurre es que el servidor haya tenido algún problema de disco que haya hecho que el fichero de la base de datos se quedara "atascado" y con la restauración se haya copiado en otra parte del disco pero son solo conjeturas.

    ¿Alguien me puede decir que ha podido pasar? Si necesitéis mas datos pedírmelos. Tengo acceso al servidor que tiene instalada la base de datos.

    Gracias y un saludo.

    jueves, 23 de mayo de 2019 15:54

Todas las respuestas

  • Una idea de qué puede haber pasado: Una aplicación que estaba accediendo a la base de datos inició una transacción y luego se quedó "colgada" por motivos distintos no relacionados con la base de datos. En ese momento, los registros a los que hubiera accedido la aplicación se quedan bloqueados. Si en ese momento ruedas otro proceso, se queda atascado en el momento en que intenta leer uno de los registros bloqueados. Pero claro, como la aplicación que lo puso está colgada, nunca quita el bloqueo y el otro proceso permanece atascado.

    Al restaurar la BD en otro equipo, los bloqueos no existen en el otro equipo y todo funciona.

    Al restaurarla sobre sí misma, tienen que cerrarse todas las conexiones y eso quita los bloqueos, y por eso funciona.

    Si eso te pasa otra vez, ejecuta sp_lock desde SSMS para ver qué bloqueos existen y cual es el SPID del proceso que ha puesto el bloqueo, y entonces hazle un Kill a ese SPID. Esto es mucho mas rapido que restaurar un backup y no requiere que los usuarios salgan de sus aplicaciones.

    jueves, 23 de mayo de 2019 16:25
  • Gracias por responder. Me  lo apunto para la próxima. Entiendo que debería de ver el proceso con el status "Block" o algo así? Lo digo para hacerme un mini-tutorial para verlo si vuelve a pasar. 

    Un saludo.

    jueves, 23 de mayo de 2019 16:32
  • Fíjate en la columna Status y busca el "WAIT":

    Captura de pantalla

    Ese WAIT indica el proceso que está "atascado" esperando que le liberen el bloqueo. Entonces en la columna Resource te fijas en el recurso bloqueado, que en este caso es  1:127:0 (que resulta ser un RID: "Row IDentifier" que indica una fila bloqueada en una tabla que no tiene clustered index). Y a continuación buscas cuál es el proceso que tiene concedido un bloqueo ("GRANT") sobre ese recurso, que en este caso resulta ser el 52 que tiene un bloqueo de tipo "X" (Exclusive) sobre ese RID.

    Puedes "romper" el bloqueo matando el proceso bloqueante: KILL 52. Y eso desbloquea el proceso que estaba a la espera (el 53) que consigue continuar con la ejecución.

    No es la única forma de hacer el seguimiento de bloqueos. Por ejemplo con un Select sobre la vista de gestión dinámica sys.dm_tran_locks se pueden hacer cosas parecidas.


    jueves, 23 de mayo de 2019 18:18
  • Muchas gracias por la explicación. Apuntada queda para la próxima. 

    Un saludo.

    viernes, 24 de mayo de 2019 7:59
  • Buen día, me sumo para dejarte otra alternativas posibles.

    Bloqueos: Sin duda podría ser la principal.

    Estadísticas: Podrías tener distintos planes de ejecución entre tus ambientes debido a distintas estadísticas entre los mismos.

    Recompilación de Planes: Muchas veces sucede que SQL no selecciona de manera eficiente el plan y se debe recompilar el store procedure

    Podrían ser varias cosas más pero por lo que comentas idices / fragmentación ya controlaste y no era el problema.

    saludos!


    Francisco Ingaramo | Microsoft Certified Professional | https://dbownerblog.wordpress.com | Votar y marcar respuestas es agradecer.

    • Propuesto como respuesta Carlos_Ruiz_M viernes, 24 de mayo de 2019 14:29
    viernes, 24 de mayo de 2019 11:50
  • Gracias por la respuesta, por desgracia mis conocimientos de sql server no son suficientes para interpretar tus comentarios. No dudo de que sean causas posibles, es solo que no se que hacer en caso de que sea por alguna de las causas que comentas. Ni para comprobarlo ni para solucionarlo. Lo único que interpreto es lo de compilar el store procedure, pero yo no tengo ningún store procedure en mi base de datos. Este bloqueo o lo que sea parte de la propia aplicación. Igual estoy diciendo una tontería, disculpad.

    Un saludo.

    viernes, 24 de mayo de 2019 16:05
  • Buenas a todos

    Me ha vuelto a pasar lo mismo que expongo en mi primer post, la aplicación se queda pillada en una consulta a base de datos y reindexo la tabla correspondiente y sigue el mismo problema. 

    Os cuento como lo he solucionado a ver si me podéis dar pistas de lo que ha pasado y porque se ha solucionado: 

    Siguiendo el consejo de Alberto Población he echado a todo el mundo de la aplicación, he ejecutado un sp_lock y he comprobado que no había ningún proceso con WAIT, aun así suponiendo que alguno era el culpable me he liado a hacer un kill de todos los procesos a lo loco. Por supuesto alguno no me ha dejado pq me indicaba que era mi mismo proceso..., y otros se regeneraban automáticamente intuyo que porque son parte fundamental del servidor y el se encarga (por suerte) de volver a crearlos. 

    Me quedo con los mínimos e imprescindibles y vuelvo a probar la aplicación inmediatamente. Sigue el problema, se queda pillada en el mismo sitio. Pienso... ¿y si la pongo sin conexión? seguro que el proceso maldito se acaba por morir si o si... Le digo que se ponga sin conexión y se queda intentándolo como 5 minutos sin dar error y sin poder cancelarlo... Así que finalizo el management studio por las bravas y lo vuelvo a abrir para hacer una copia de seguridad pq ya me estaba empezando a asustar... Abro el dialogo de copia de seguridad y antes pienso en volver a probar la aplicación y ¡¡¡TACHAN!!! se ha solucionado, ya no se queda bloqueada....

    Así que pienso que o bien los kill (que quizás tendría que haber esperado un poco a probar la aplicación) o el intento de ponerla offline han terminado matando lo que sea que interfería. Pero claro me queda la duda de que no se muy bien como lo he solucionado y peor aun no se porque se produce esto. Es la segunda vez en 5 años que me pasa y no hace ni un mes que me paso por primera vez... ¿Esto va a peor?

    La aplicación que es la única que tira de la base de datos va creciendo pero no hace nada especial de un tiempo a esta parte.

    Como veréis estoy bastante pegado en cuestiones de administración de base de datos pero es lo que hay... soy el encargado de todo lo relacionado con el programa.

    Un saludo y gracias.

    jueves, 20 de junio de 2019 15:42
  • A ver si alguien tiene algún consejo. 

    Un saludo

    viernes, 21 de junio de 2019 7:11
  • Si es algo intermitente que solo ocurre en ciertas ocasiones, podrias dejar habilitada una traza con el SQL Trace (o con Extended Events), de forma que cuando ocurra el error puedas acudir a la traza y ver qué se estaba ejecutando justo antes de quedarse atascado.
    viernes, 21 de junio de 2019 10:48
  • Gracias por la respuesta, 

    Me surgen varias dudas con respecto a tu consejo:

    1.- ¿Está disponible para SQL Server 2012 Express?

    2.- ¿Al habilitar la traza se penalizará de alguna forma la velocidad de respuesta/rendimiento del motor sql? Vamos que si no la liaré y dejara de responder el programa.

    3.- ¿Existe algún riesgo para la base de datos por poner una traza o es un proceso seguro?

    4. Sql Trace o Extended Events para mi son palabras que acabo de oír hoy. ¿Cual me recomiendas?

    5. Y la última y no menos importante. ¿Seré capaz de sacar algo en claro de la traza? Osea ¿me va a mostrar la consulta o lo que sea que estuviera ejecutándose cuando se queda atascado? Porque el tema es que la aplicación funciona perfectamente y es solo en determinada parte (que ha variado de un atranque a otro pero que siempre está relacionada con la misma tabla, la mas grande de la base de datos) que se queda atascado. 

    Siento tanta pregunta pero estoy mas perdido que una vaca en un garaje....

    Gracias y un saludo.

    viernes, 21 de junio de 2019 15:57
  • 1) Sí, el SQL Trace existe para la edición Express, pero es un poco molesto de configurar. Normalmente se suele usar el Profiler, que tiene una opción de menú que te genera el script para activar la traza. Pero en la edición Express no se puede usar el Profiler (aunque sí funciona el script si lo has generado por algún otro medio). Una opción es generar el script en un equipo de desarrollo donde tengas instalada la edición Developer (gratuita) y luego ejecutar el script en el equipo donde está la Express. Otra es estudiar los comandos y escribir el script a mano.

    2) La traza sí que influye en la velocidad de respuesta. Solo la afectará ligeramente si eliges con cuidado los filtros de la traza para que no sea muy verbosa. Recomiendo hacer pruebas primero en un equipo de desarrollo antes de activarla en producción.

    3) Es un proceso seguro. No puede dañar la base de datos de ninguna manera (pero sí puede perjudicar a la velocidad como hemos dicho antes).

    4) Lo más moderno es los "extended events". No estoy seguro de la versión mínima que requiere, no sé si en la versión 2012 está disponible, ni tampoco si se puede usar en la edición Express. En cambio, la traza es "lo de toda la vida", bien probado y conocido. Si fuera para mi, yo usaría la traza, pero eso es porque la conozco mejor; no afirmo de ninguna manera que sea más eficiente que los extended events.

    5) Leer las sentencias SQL desde la traza es fácil. Aparecen en claro tal como las envía el programa cliente. Pero deducir cuál de ellas se "atasca" (y por qué) puede no ser nada fácil. Requiere que alguien con amplios conocimientos de SQL Server elija los datos que interesa capturar en la traza y sepa después analizarlos.

    viernes, 21 de junio de 2019 18:46
  • Muchas gracias por las aclaraciones.

    Un saludo.


    hace 19 horas 45 minutos