Hilo iniciado por César Chamorro el 6 de abril de 2010
-
Entradas
-
Hola a todos!
Creo que voy a tener el placer de inagurar el grupo de NAV. Como veo que ninguno nos decidimos y eso que ya somos unos cuantos, empezaré que un tema que tenemos atravesado desde hace un tiempo y que no terminamos de solucionar, os cuento.
Tenemos un proceso para cargar, en “background” (= formulario en el servidor siempre abierto que se ejecuta con un OnTimer), los fichajes de proyectos/producción. Esté lee un fichero txt que carga en el diario de proyectos/ de salida y lo registra, hasta aqui todo bien.
El problema nos surge cuando alguna de las tablas que utiliza el diario se encuentra bloqueada por otro usuario, entonces el proceso se queda bloqueado a la espera de validar el mensaje de aviso en la pantalla del servidor. Por lo que tenemos que estar comprobando de forma regular si ha habido algún problema, además mientras tanto se pueden haber cerrados los proyectos/OPs sin haber cargado todo el coste, etc…
¿alguna otra manera de programar estos procesos background? Si no fuera posible ¿alguna manera de controlar estos bloqueos? ¿o al menos alguna manera de saber que el proceso del servidor esta esperando a que validemos el aviso de bloqueo?
Muchas gracias por vuestra ayuda.
Buenas
Según entiendo lo estais gestionando todo por código y sin añadir recursos automáticos (NAS, cola de eventos,….). También entiendo que es crítico que se carguen on line los costes generados en las OP/Proyectos.
Mi consejo es que chequees la criticidad de dicha generación online de costes (a primera vista no parece tan crítico) y poder acumular en los diarios correspondientes la información. Unir a ésto una programación que te permita verificar si las tablas estan bloqueadas y lanzar el registro .
Otra solución es la utilziación del NAS y del job scheduler. Es sencillo, escalable y de fácil seguimiento.
Finalmente y basándome en mi experiencia, todos estos bloqueos inoportunos vienen dados por las personalizaciones que se realizan a los clientes. Identificar estos cuellos de botella y solucionarlos puede arreglar el problema sin tener que tocar nada de lo que actualmente está desarrollado para este proceso background.
Esperando haber ayudado
J
Hola, César! Lamento decirte que con el NAS tampoco solucionarás el problema, aunque se mejora bastante. Pongamos este ejemplo: instalo y configuro el NAS con la cola de proyectos y lo programo para que se ejecute cada 10 minutos. Mientras se ejecuta el proceso surge un error (no sé, un error de bloqueo, o un error de datos incorrectos, etc…), el proceso también se detiene. Y se vuelve a lanzar dentro de 10 minutos. Verías el mensaje de error en los movimientos de registro de la cola de proyectos, pero nada más. Quiero decir, que ganas el “reintento” y en caso de bloqueo, el proceso sí se ejecutaría, aunque dentro de 10 minutos. Sin embargo, si es un error de datos, u otra cosa, no te evitas tener que comprobar de forma regular si ha habido algún problema.
Si estuviera en tu lugar, intentaría solucionar el problema de bloqueos. ¿Es con SQL Server o propietario? (ya sabrás que la cosa cambia).
Espero haberte ayudado (llego tarde a tu mensaje pero es que soy nueva en el foro).
Bueno, no tengo ni idea de NAV pero os agradezco el “atrevimiento” de empezar con los debates…que parecía esto el Rincon de Dynamics “AX” :)…
Gracias por participar y a ver si se anima más gente 🙂
Muchas gracias a ambos por vuestras respuestas.
Por lo que respecta a la criticidad del proceso, si bien la carga de los fichajes de los proyectos se podría hacer en acumulados diarios, para los fichajes de producción resulta inviable, dado que por diferentes razones, a día de hoy la única manera que tienen de imputar el producto fabricado es con el cambio de estado de la OP a terminada (método retroactivo), y por tanto habría que esperar al día siguiente para poder sacar el producto fabricado del almacén.
Voy a empezar a ver como funciona el NAS y ver si nos puede servir dado que el gran de mayoria de incidencias se deben a bloqueos.
Mayte, en nuestro caso trabajamos con SQL Server ¿podríamos intentar controlar los bloqueos desde aquí? ¿Se podrías expicar cómo?
Gracias de nuevo.
Para saber que sentencias de código realizan bloqueos en las tablas debes utilizar la opción “Code coverage” que se encuentra en el menú Herramientas->Debugger. Esta opción t devuelve información de cada una de las sentencias de código C/AL que se ejecuta y te informa de varias cosas entre ellas si bloquea una tabla y que tabla bloquea.
A partir de ahí, intuición y experiencia para ir acotando cuáles son las sentencias que bloquean inecesaria e ineficientemente.
Un par de consejos:
* Genera mucha información, te recomiendo que empieces de menos a más. Así puedes copiar en una hoja excel los resultados y trabajar con ellos.
* Centrate en los bloqueos que duren más y resuelvelos, el resultado será antes visible.También creo recordar que en la partnersource hay un documento sobre malas prácticas de programación y consejos básicos como solucionar posibles bloques de código ineficientes.
Espero servir de ayuda
J
Hola! Si estuviera en tu lugar, empezaría por comprobar si estoy utilizando bien los índices.
Nota: si la versión es inferior a la 4.0 SP3, comprobaría que las tablas que utilizo tengan la clave primaria como índice agrupado (clustered). Luego comprobaría si los tengo con un factor de relleno (en SQL Server) adecuado. Nota: si es SQL Server 2008 puedes comprobar que bloquea filas de índice y no páginas de índice. Después, comprobaría si Dynamics los está utilizando correctamente: me aseguraría de que antes de “SETRANGE” / “SETFILTER” siempre hubiese un “SETCURRENTKEY” con los campos en el mismo orden que los fltros. También me aseguraría de que la propiedad “Mantener SIF” es “NO” en los índices que no necesito. Muchas veces, se producen bloqueos porque SQL tarda más tiempo del previsto en resolver una consulta. Si las consultas se resuelven rápido, los bloqueos disminuyen mucho. Puede ser que tengas que crear índices nuevos, aunque si creas demasiados, bajará el rendimiento en las inserciones/modificaciones/eliminaciones.
También viene muy bien crearse planes de ejecución que se ejecuten por la noche para regenerar índices y actualizar estadísticas. De esta forma, durante el día no necesita volver a calcular estadísticas y resuelve más rápido.
Y por último, comprobaría si las instrucciones C/AL son adecuadas. Por ejemplo: en lugar de utilizar FIND(‘-‘) en un bucle REPEAT…UNTIL, es mejor utilizar FINDSET, etc…Espero haberte ayudado. Ya nos contarás si se mejora el proceso. ;p
Hola César,
No soy técnico, por tanto no entraré en el detalle, pero sí te recomiendo un par de soluciones de ExpandIT que creo pueden ayudarte con este reto.
¿alguna otra manera de programar estos procesos background?
ExpandIT Launch Utility: Te permite programar el lanzamiento automático y desatendido de cualquier objeto de NAV que programes (Dataports, Codeunits, Reports, etc). Puedes encadenar distintos lanzamientos por la noche y no es necesario dejar ninguna sesión de NAV abierta.
Si no fuera posible ¿alguna manera de controlar estos bloqueos?
Si los procesos se pueden lanzar automáticamente por la noche, hay otra utilidad de ExpandIT (Client Control) que te permitirá cerrar todas las sesiones trascurrido cierto periodo de inactividad y por tanto entiendo que solucionaría los problemas de bloqueos.
http://www.expandit.es/templates/expandit_square.asp?Catalog_ID=707
Espero sea de tu agrado y te ayude en algo.
Un saludo
ChemaGracias a todos por vuestras respuestas,
y perdonar que no haya contestado, aunque en su día si que las leí y las tuvimos en cuenta a la hora de introducir una serie de modfiicaciones que han mitigado el problema, aunque todavía se producen bloqueos con una cierta frecuencia.
Un saludo,
César.
- Debes estar registrado para responder a este debate.