SQL Server Performance

problema con procesos bloqueados

Discussion in 'Preguntas sobre SQL Server en Español.' started by rsegoviano, Apr 1, 2009.

  1. rsegoviano New Member

    Estimados Señores:
    Tengo un servidor con Windows Server 2003 Enterprise Edition y SQL Server 2005. Tenemos trabajando un sistema de punto de venta via HTTP programado con Powerbuilder y Appeon (traductor de powerbuilder a java) y un servicio Jaguar que da el servicio de las paginas http a los usuarios que se conectan.
    El problema que tenemos es que cada determinado tiempo (pueden pasar varios dias) tenemos procesos que estan bloqueando y que no estan bloqueados por nadie y que no se desbloquean. Esto produce que los otros procesos comiencen a bloquearse y estos a bloquear a otros hasta que se cae el servicio del Jaguar y el SQL no responde hasta que tumbamos el servicio de jaguar (despues de esto SQL server vuelve a responder) y volvemos a levantar el Jaguar y se tienen que volver a conectar todos nuestros usuarios.
    Normalmente el proceso que se bloquea es un Update a una tabla de notas de venta.
    Preguntas:
    ¿ Bajo SQL Server un proceso que no está bloqueado por nadie, debería de terminar y desbloquear a los demas?
    ¿ Bajo que circunstancias un proceso bloqueador no termina ?
    El sistema de punto de venta de que hablamos fue desarrollado por un outsourcing y el me dice que se necesita un reindexado de la tabla para mejorar su performance y que no se atore el proceso, pero yo pienso que una cosa es que sea lento y otra que se quede atorado por siempre sin desatorarse por si mismo.
    Agradezco de antemano cualquier ayuda.
  2. Luis Martin Moderator

    Bienvenido al Forum!!.
    "¿ Bajo SQL Server un proceso que no está bloqueado por nadie, debería de terminar y desbloquear a los demas? "
    Si un proceso no está bloqueado por nadie debería terminar. Si ese proceso, a su vez, estaba bloqueando a otros, al finalizar se desbloquea el primer proceso que intentó acceder a la tabla y no pudo por el bloqueo del original.
    "¿ Bajo que circunstancias un proceso bloqueador no termina ?"
    Bajo un time out. En este caso el SQL mata al proceso dado que hace mucho tiempo que está bloqueado.
    "El sistema de punto de venta de que hablamos fue desarrollado por unoutsourcing y el me dice que se necesita un reindexado de la tabla paramejorar su performance y que no se atore el proceso, pero yo pienso queuna cosa es que sea lento y otra que se quede atorado por siempre sindesatorarse por si mismo."
    Siempre debe haber trabajos de mantenimiento que incluyan el reindexado de aquellos índices que están con alto grado de fragmentación.
    Ahora, supongamos el siguiente escenario:
    Si para realizar un update a una sola tabla que contiene los números de notas de ventas, (update xxxx set numero = numero + 1) para que la siguiente nota de venta tenga un número único y, existen varios puestos de trabajo que quieren generar otras notas al mismo tiempo, entonces es lógico que ocurran los bloqueos.
    Tendrías que preguntarle a los desarrolladores cómo es el modelo de datos para las notas de ventas
  3. rsegoviano New Member

    Gracias Luis Martin por tu respuesta.
    Pero dejame comentarte lo siguiente:
    El flujo de sucesos es el siguiente :
    Nosotros estamos monitoreando el servidor (Rendimiento) y lo mas importante para nosotros son los procesos bloqueados. Es normal cuando se bloquea un proceso y despues de uno o dos segundos se desbloquea solo. Lo anormal sucede cuando despues de una vuelta (1:40 minutos) nos muestra que hay procesos bloqueados y no se desbloquean. Entramos al Monitor de Actividades y actualizamos y encontramos un proceso que tiene en el campo "bloqueado por" un cero y en el campo "bloqueo" un 1. Revisamos que es lo que está haciendo el proceso y normalmente está haciendo un insert into notas_vta aunque a veces el proceso que bloquea es un stored procedure ( que inserta en otra tabla notas_vta_detalle). Este proceso comienza a bloquear a otros procesos. Si nosotros no intervenimos, comienza a crecer el numero de procesos bloqueados ya sea por este proceso o por otro proceso que a su vez es bloqueado por el proceso origen.
    Lo normal si nosotros estamos monitoreando la actividad en ese momento, es que cancelemos el proceso origen y normalmente se resuelva el problema ahi ( eso sin tomar en cuenta si alguien en nuestra cadena de tiendas tuvo un error por el kill del proceso).
    Si nosotros no estamos monitoreando la actividad (fuera de nuestro horario de oficina, pero que todavia están abiertas las tiendas), entonces este número de procesos bloqueados sube hasta generalmente 267 o algo así y entonces el SQL no responde ( si entramos a Monitor de Actividad no hace la actualización) ni con el Management Studio (no hay conexion con el servidor y no se puede volver a conectar) por eso digo que se cae el SQL aunque esto no es cierto completamente. Cuando me reportan via telefónica de alguna de las tiendas que no hay servicio, entonces me conecto al servidor, y quito el programa Jaguar que está trabajando siempre dando servicio de páginas http. Al tumbar el Jaguar, automaticamente se terminan los procesos bloqueados y bloqueadores y el SQL me vuelve a responder así como el monitor de actividad.
    Despues de esto, vuelvo a arrancar el Jaguar, y todas las tiendas comienzan a conectarse y a volver a trabajar.
    Mi pregunta "¿ Bajo que circunstancias un proceso bloqueador no termina ?" se referia a que si hay circunstancias en que un proceso se "atore" bloqueando a los demas, sin que esté atorado aparentemente por ningun otro proceso, esto es, que indique "Bloqueado por" =0 y "Bloqueo"=1.
    En lo que estaba escribiendo este post, sucedió esto que te platico y tuve que intervenir para evitar una caida del sistema
    Con respecto al escenario que planteas : Si varias personas al mismo tiempo tratan de hacer un update, no se supone que SQL es lo suficientemente inteligente como para decir : primero atiendo a uno, que los demas se esperen (bloqueados), despues atiendo a otro, y asi sucesivamente ? Yo no tengo dudas con respecto a que existan bloqueos, lo que no entiendo es que un proceso que no esta bloqueado por ningún otro, se quede en ese estado por siempre, bloqueando a mas y mas y mas hasta que truena el sistema.
    Yo (por mi edad, "soy viejito") vengo de los equipos viejitos, en especial de una marca "alpha micro" que maneja un ISAM con un bloqueo manual, no automatico, en el cual le tienes que decir: , como voy a dar una alta, entonces bloquea todo el archivo, doy el alta, desbloqueo el archivo, o si voy a realizar una modificación, entonces bloqueo el registro, hago la modificación, y luego desbloqueo el registro. Cada que intento hacer un bloqueo debo de preguntar si fue existoso el intento, y si no, esperar unos segundos o a que el usuario decida si quiere realizarlo en mejor ocasion, o ponerlo en una cola PEPS y que se espere hasta que le toque. No creo que SQL Server sea más tonto que ese sistema arcaico.
    ¿De que manera puedo programar para que un proceso que está determinado tiempo bloqueando a los demas, tenga un "time out" como me indicas? ¿Que tiempo sería conveniente ponerle a este "time out" para empezar a probar?
    Gracias de antemano por tu ayuda
    Ing. Roberto Segoviano
    León Gto. México
  4. Luis Martin Moderator

    No creo que tengas 60 años como yo.[:)]
    En mi opinion el problema está en la aplicación y no en el SQL.
    Una aplicación en donde los procesos de ventas se graban on line y tienes muchos usuarios grabando ventas, tiene que estar muy bien diseñada para no tener bloqueos.
    Hay ocasiones en las cuales ocurren dead locks. Esto ocurre cuando se produce un bucle de bloqueos entre procesos.
    Te sugiero lo siguiente: Instalá el SQL SPY 6 que es gratuito. Este producto te mostrará exactamente la secuencia de bloqueos y quién la inició.
    No hay forma de programar un proceso como el que tu deseas para el time out. Podrías programar un alerta para cuando no están en la empresa y resolver en forma remota.
    Insisto con averiguar si es una sola la tabla en donde se graban los número siguientes de las notas de ventas.

Share This Page