Demoras en la ejecución de la operación cub_0006 "Genera datos temporales DW"

Estimados:

En la Universidad Nacional del Sur, nos encontramos con problemas de demoras en la operación cub_0006 “Genera datos temporales DW”, que figura en el submenú “Interfaces” → “Guaraní-DataWare House”. Esta operación inicializa dos tablas temporales para la exportación de archivos txt que se utilizan en la generación de cubos de rendimiento académico.

Siguiendo el código fuente, llegamos a la ejecución del stored procedure sp_int_dw_i_per, que es el segundo de los dos SP que ejecuta la operación cub_0006. En la UNS, este stored procedure demora más de 24 horas.

Para el tiempo indicado, se debe considerar que las tablas sga_carrera_aspira y sga_personas contienen respectivamente 187.257 y 110.539 registros; y que luego de la ejecución de la operación cub_0007, las tablas temporales int_dw_alumnos_red y int_dw_persona_red contienen 170132 y 110539 registros.

Luego de haber analizado el código del stored procedure sp_int_dw_i_per, encontramos y proponemos la siguiente solución:

  1. En el stored procedure sp_int_dw_i_per se encontró una consulta que produce un producto cartesiano entre las tablas sga_carrera_aspira y sga_personas, ya que no se cruzan los campos clave correspondiente en la expresión del WHERE. Para la última versión 2.9.1, en la SQL de la línea 108:

...
   SELECT COUNT(DISTINCT carrera)
     INTO vi_car_aspira
     FROM sga_carrera_aspira,
          sga_personas
    WHERE sga_carrera_aspira.unidad_academica = vc_UA
      AND sga_carrera_aspira.nro_inscripcion = vc_NRO_INSCRIPCION;
...

Para corregirlo, se debería eliminar la referencia a sga_personas en el FROM, quedando la siguiente consulta:


...
   SELECT COUNT(DISTINCT carrera)
     INTO vi_car_aspira
     FROM sga_carrera_aspira
    WHERE sga_carrera_aspira.unidad_academica = vc_UA
      AND sga_carrera_aspira.nro_inscripcion = vc_NRO_INSCRIPCION;
...

  1. El tiempo total del procesamiento se puede disminuir aun más si se agrega un índice adicional a la tabla int_dw_alumnos_red, incluyendo los campos unidad_academica y nro_inscripcion, que se utilizan en la SQL de la línea 118:

...
   SELECT SUM(CNT_READMISIONES),
          MIN(ANIO_INGRESO)
     INTO vi_CNT_READ,  
          vi_AnioIngreso
     FROM int_dw_alumnos_red
    WHERE unidad_academica = vc_UA
      AND nro_inscripcion  = vc_NRO_INSCRIPCION ;
...

Se justifica el nuevo índice porque la consulta no utiliza el de la clave primaria (unidad_academica, carrera, legajo).

El índice propuesto sería:


   CREATE INDEX idx_int_dw_alu_ni 
      ON int_dw_alumnos_red (unidad_academica, nro_inscripcion);

Resultado:

En el caso particular de la UNS, el proceso de inicialización que tardaba más de un día en ejecutarse, pero con las modificaciones propuestas, demora solo dos minutos.

Saludos,
Pablo Revel,
UNS.

Hola Pablo, gracias por avisar sobre el bug en ese procedure (la tabla sga_personas estaba demas en ese FROM como lo indicas) y es correcto el agregado del indice en la tabla temporal ya que se accede siempre con los datos de una persona y al tener tantos registros la diferencia entre entrar en forma secuencial a la tabla y no por indice es significativo.
Lo incluiremos en version 2.9.2
Se ve que cuando se testeó esta interfaz seguramente se realizó en bases con pocos alumnos con lo cual esto no fue detectado.

Gracias!