Retardo variable en un SELECT???

[Driau]

Hola a todos,

Se que el título no es muy entendedor pero si os explico un poco supongo que lo será.

Tengo un listado que hace unas selecciones mediante el (código de material y año) y las saca por pantalla en un ALV. El problema de dicho listado es que si listo un material qualquiera (digamosle "X") tarda 5 segundos, pero al cabo de unas horas vuelvo a listar exactamente el mismo material y tarda 40 segundos. A la mañana siguiente lo repito y tarda 23 segundos. Es decir existe una variabilidad en el tiempo inexplicable (por lo menos para mi) que me tiene loco. Yo he debuggeado el código y el sitio en donde se encalla clarísimamente es esta SELECT:

SELECT *
INTO CORRESPONDING FIELDS OF TABLE t_mseg
FROM mseg
INNER JOIN mkpf
ON mkpf~mblnr = mseg~mblnr
AND mkpf~mjahr = mseg~mjahr
WHERE mseg~matnr = p_matnr
AND mseg~werks = 'CENT'
AND mkpf~budat <= fecha_dic
AND mkpf~budat >= fecha_ene
AND mseg~lgort <> ''
. "Fin Select

Hemos reorganizado los índices de la tabla de base de datos y hemos vuelto a generar la tabla de estadísticas.

La verdad...si tarda 60 segundos siempre...pues bueno. El problema es esta varición en el tiempo para un mismo caso. Alguien sabe de que puede ser??

[ballan]

Las tablas MKPF y MSEG son tablas enormes (ademas la MSEG es un cluster, a grosso modo es que se forma con trozitos de otras tablas) por lo tanto los accesos te van a llevar mucho tiempo

Ademas el planificador de BBDD puede determinar un camino de seleccion distinto cada vez, unas veces te va por un indice y va mas rapido, otras por otro y va mas lento, etc..

Las cosas que puedes ir probando para optimizarlo son :

Cambia la estructura de la tabla T_MSEG para que en lugar de hacer into corresponding fields of tabla .. hagas INTO TABLE t_mseg

Aun mejor seria que en lugar de hacer select * hicieras un select trayendote solo los campos que utilizas

Los campos del where deben ir en el mismo orden que estan declarados en las tablas por ejemplo la condicion LGORT <> '' deberia ir despues del werks

Los indices solo funcionan con comparaciones de igualdad por lo que aunque suponga un esfuerzo extra a veces merece la pena hacer selecciones para conseguir esto

Por ejemplo en lugar de poner LGORT <> '' puedes ir a la tabla T001L, seleccionar todos los almacenes, meterlos en un rango y poner en tu select la condicion LGORT IN s_lgort, esto tambien aplicaria para el budat, seleccionando las fechas comprendidas y metiendolas en un rango


SELECT *
INTO CORRESPONDING FIELDS OF TABLE t_mseg
FROM mseg
INNER JOIN mkpf
ON mkpf~mblnr = mseg~mblnr
AND mkpf~mjahr = mseg~mjahr
WHERE mseg~matnr = p_matnr
AND mseg~werks = 'CENT'
AND mkpf~budat <= fecha_dic
AND mkpf~budat >= fecha_ene
AND mseg~lgort <> ''

[Driau]

He estado leyendo y releyendo tu post. estoy de acuerdo en todo ya que seguro que me ayuda a mejorar la velocidad de respuesta del programa. Pero como te comento, lo mas raro es la variabilidad en el tiempo de respuesta para una misma búsqueda así que me he fijado especialmente en el punto en que me comentas esto:

"pero como te comento Ademas el planificador de BBDD puede determinar un camino de seleccion distinto cada vez, unas veces te va por un indice y va mas rapido, otras por otro y va mas lento, etc.."

Me podrías detallar o profundizar un poco mas en esto del planficiador??? Creo que puede ser interesante y podría explicar estas variaciones de retardo.

Gracias nuevamente

[ballan]

Bueno lo primero es destacar que los planificadores de BBDD son herramientas muy complejas asi que intentare hacer un pequeño resumen y me tomare algunas "licencias"

Basicamente el planificador de BBDD lo que hace es analizar la sentencia SQL en base a una serie de parametros

-Datos estadisticos -> Cada cierto tiempo se pueden elaborar estadisticas de la BBDD y si por ejemplo sabemos que en una tabla hay muy pocas entradas que empiecen por Z y realizaramos un select buscando que ese campo empiece por Z el planificador podria obviar la seleccion por la clave principal y determinar la seleccion por otro indice o incluso un full scan de la tabla porque por medio de las estadisticas "sabe" que va a recuperar muy pocas entradas y le puede compensar

-Datos inherentes a la BBDD -> Si tu BBDD tiene definido un indice por campo1 campo2 y campo3 y tu haces
select ..
into..
from..
where campo1 = ...
and campo2 = ..
and campo3 = ..

El planificador veria que hay un indice que contiene todos los campos por los que quieres seleccionar y PROBABLEMENTE determinaria la seleccion por dicho indice

Digo probablemente porque los algoritmos de planificacion de BBDD son bastante complicados y afectan un monton de variables, como puede ser la carga de trabajo que esta soportando la maquina, el numero de personas que haya accediendo en paralelo y una multitud de condicionantes mas

Es por eso que una misma sentencia select la ejecutas una vez y hace la seleccion por un camino y la ejecutas inmediatamente despues y existe una posibilidad de que el planificador determine otro camino por alguna razon de las antes expuestas

En SAP disponemos de la transaccion ST05 que sirve para hacer trazas SQL, puedes activar la traza SQL, luego realizar una operacion cualquiera (ejecutar un listado, llamar a un report, crear un pedido o lo que sea) luego vuelves a la ST05, desactivas la traza y visualizas el resultado

Observaras que te aparecen todas las sentencias SQL que se han realizado para lo que hubieras ejecutado, si pinchas en el explain observaras que te dara informacion mas exhaustiva de la operacion SQL, te dira a traves de que indice se ha realizado el select, el coste que ha tenido, etc

Para saber el retardo variable lo que yo miraria son dos cosas, realizaria varias trazas del mismo proceso para ver si unas veces pasa por un indice y otras por otro y tambien me fijaria en la transaccion SM50 en la carga de trabajo que esta soportando la maquina en el momento del lanzamiento del programa, quiza por ahi puedas ver algo