Buenos días, quería realizar una consulta. Estamos realizando la migración de la Facultad de Derecho a Guarani2 y notamos una performance bastante lenta con el pasaje de equivalencias a las tablas sga_examenes_equiv y sga_equiv_equiv.
El SP que usamos es sp_equiv_auto y lo tenemos que ejecutar para 17.000 legajos, sobre un total de 400.000 registros en sga_detalle_acta. Aproximadamente procesaba 300 legajos por hora y tardo más de 2 días en terminar.
Tenemos un servidor con 8 procesadores, 4gb de ram y Windows Server 2003 y nunca supera el 15% de uso de procesador y 1gb de ram mientras esta corriendo el proceso, nunca se satura el servidor y responden perfectamente el G3W y la aplicación de Gestión.
La pregunta es la siguiente, se puede configurar en el informix algún parametro del ONCONFIG para dar mayor prioridad al proceso???
Las veces que yo tuve que hacer trabajos similares para poblar las tablas sga_examenes_equiv, sga_equiv_equiv, sga_promo_equiv y sga_cursadas_equiv con unos scripts especiales que tengo para eso (desarrollado en los albores del SIU), era un proceso medio pesado pero nunca al punto de lo que vos comentás.
Esto es porque son SP que invocan a otros SP en cascada y creo que usan tablas temporales.
Pero de todas maneras creo que vale la pena ver la configuración del Informix para ver si está utilizando los 8 procesadores, los 4 GB de RAM y otros temas. Además habría que ver como están las estadísticas de la base que si están desactualizadas puede influir drásticamente en la performance.
Si vos decís que procesaba 300 legajos por hora y tenés que procesar 17.000 es lógico que tarde más de 2 días … Lo que hay que ver es si es lógico que procese 300 legajos/hora, que serían 5 legajos por minuto, o se puede mejorar algo.
Probaron corriendo update statisctics para la base de datos y para los procedures ?
Yo ejecutaria un UPDATE STATISTICS LOW y luego un UPDATE STATISTICS FOR PROCEDURES a ver si cambia algo
el asunto es que si ya estan corriendo el procedure de migracion lo tendrian que cortar, ejecutar los UPD STATS y luego continuar con el procedure. No se si tiene capacidad de reprocesar a partir de donde fue cortado
Pablo, ese proceso lo desarrollaron ustedes? Te pregunto esto porque no veo que este en el catálogo de los procedures del SIU.
Si es asi, verificaste que esten bien realizadas las consultas que hay alli? es decir que accedan correctamente a cada taba por los indices? En algunos casos es necesario usar tablas temporaes para mejorar los procesos…
Si este es el caso si queres envia el proceso y lo verificamos.
Ademas de esto, tienen actualizadas las estadisticas de los datos de las tablas?
Ese SP es un SP que armamos en la UNSAM con Cesar Donofrio, allá por el 2000 como complemento a los scripts de migración para el caso de materias comunes que estaban en más de 1 carrera, y que yo utilicé reiteradas veces en las implementaciones que participé y lo fui completando / mejorando. Lo que no sé es de donde lo obtuvo Pablo, si el SIU se quedó con alguna versión de esa época y se la pasó o de donde lo sacó.
1- El script que usaste requiere hacer 2 pasos, el primer paso es para generar otro script llamado c:\updstssql.sql que tiene los comandos Update statistics. el 2do paso consiste en ejecutar el script generado en el primer paso. Ejecutaste el script updstssql.sql ?
2- Aun cuando hayas ejecutado los dos pasos mencionados en el punto 1- ese script no incluye comandos update statistics for PROCEDURE, yo te sugiero seleccionar tu base de dato y correr un :
UPDATE STATISCTICS FOR PROCEDURE ;
que re optimiza todos los procedures en la base de datos
Con respecto al ONCONFIG le di una mirada y parece estar bien. Si tenes memoria libre en el servidor se podria subir el parametro BUFFERS de 10000 a 20000 / 30000
Pablo mejore el codigo del procedure.
En principio solo consultar por materias que sean comunes con las otras carreras del alumno.
Por otro lado en los INSERT … NOT IN … Aqui faltaba el join por unidad_academica y carrera, ya que solo se buscaba por el legajo del alumno, lo cual hacia que no accediera por indice y si fuera que manejan diferentes legajos por carrera, podria ser que exista otro alumno con el mismo legajo en otra carrera…
1- Es correcto como decís, luego ejecuto la salida “updstssql.sql”.
2- Me olvidé de mencionarlo pero, también corrí el UPDATE STATISCTICS FOR PROCEDURE.
3- Voy a probar el cambio que me sugerís de BUFFERS de 10000 a 20000 / 30000.
4- Otra consulta OFFTOPIC, en el mismo servidor nos pasó el siguiente error: “-211 [Cannot read system catalog (systables)”, y se solucionó reiniciando el servicio. ¿Tenés idea que pudo haber pasado?
Hola Alejandro, voy a probar el SP y te cuento, lo tengo que depurar porque me tiró error, pero seguramente que debería mejorar con los cambios que me comentas.
Hola Alejandro, buen día. Ahi probé el SP con el cambio y mejoro bastante, pasamos de 30 segundos por legajo a 10 segundos. Aunque sigue siendo un proceso lento calculo que es normal por todas las tablas que consulta.
ok. Igual 10 segundos por alumno pareciera ser mucho tiempo. ¿Corriste el Update Statistics?
Adjunto un archivo que crea sentencias del update statistics.