Hola a todos los que particip�is en el tema:
Primero, dos precisiones:
- Estoy completamente de acuerdo con Manuel, la �nica pista la encontrar�s
con DEBUG, aunque es posible que no encuentres la soluci�n.
- Lo de especificar ORDER BY para forzar la elecci�n de una v�a de acceso,
es puro camelo.
Fantas�as:
- Seg�n algunos expertos, una forma de "sugerir" al optimizador que utilice
la V�a de Acceso asociada a un fichero l�gico, aunque es imposible
forzarlo, es especificar dicho Fichero L�gico en la sentencia Select del
SQL.
- De hecho, s�lo funciona, y no siempre, cuando sobre el fichero F�sico hay
una gran cantidad de V�as de Acceso y en el DEBUG te indica que no se han
revisado todas por falta de tiempo y adem�s la que t� quieres no aparece en
la lista de V�as de Acceso estudiadas y rechazadas, ya que si la ha
rechazado, ya puedes inventar que no consigues nada.
Misterios del Optimizador:
- Seg�n parece, a la hora de decidir una V�a de Acceso, son m�s importantes
los criterios de selecci�n (WHERE), que los criterios de ordenaci�n (ORDER
BY).
- Hay veces que teniendo una sola V�a de Acceso, que se corresponde
exactamente con los criterios de selecci�n, el optimizador decide crear una
nueva V�a de Acceso temporal ��Id�ntica a la Existente!!, y adem�s tiene
las narices de sugerirte que crees una similar para mejorar el rendimiento.
Si lo haces, sigue despreci�ndola, sigue creando una temporal, pero ya no
te aconseja nada.
- Lo report� a IBM y desde Rochester me enviaron una larga explicaci�n, de
m�s de dos p�ginas, justificando el comportamiento del optimizador. La he
rele�do una docena de veces y sigo sin entender el motivo. No hay soluci�n.
Recomendaciones finales:
- Resulta muy interesante estudiar los mensajes que el optimizador facilita
cuando se ejecuta en SQL en modo DEBUG, ya que algunas veces aunque las
sugerencias son un poco extra�as y aparentemente injustificadas se
consiguen mejoras de rendimiento del orden del 20 al 40%
- Si ten�is alguna aplicaci�n que consume mucho tiempo de CPU, utiliza SQL
u OPNQRYF, y se ejecuta frecuentemente, deber�ais probarla con DEBUG y
estudiar los resultados.
- IMPORTANTE: El estudio se debe hacer en entorno de explotaci�n, ya que el
n�mero de registros y los valores de los diferentes campos pueden alterar
los resultados ofrecidos por el Optimizador. Quiero decir que una s V�as de
Acceso que en un momento favorecen el rendimiento, pueden ser ignoradas
cuando cambian las circunstancias.
Saludos,
---------------------------
Santiago Mart�
Dusen, S.A.
---------------------------
"manuelgonzalez.servic
us.es" Para: [EMAIL PROTECTED]
<manuelgonzalez@servic cc:
us.es> Asunto: Re: RE: QQAINI
Enviado por:
forum.help400-request@
combios.es
01/03/2002 10:31
Por favor, responda a
forum.help400
Averiguar por qu� SQL usa un m�todo de acceso y no otro, es junto con
la composici�n de la cocacola uno de los grandes enigmas de la
humanidad.
b) Si ejecutas el SQL bajo DEBUG (no es necesario marcar puntos de
interrupci�n) podr�s leer en los mensajes detallados del trabajo,
porqu� se eligi� una via de acceso y no otra para la ejecuci�n del SQL,
e incluso una sugerencia de que indices deber�a haber para que la
sentencia dse ejecutara m�s r�pidamente.
----- Mensaje Original -----
Remitente: "jose hernandez" <[EMAIL PROTECTED]>
Fecha: Jueves, Febrero 28, 2002 5:18 pm
Asunto: RE: QQAINI
> Hace a�os IBM dec�a que para forzar el optimizador en elegir el
> fichero que
> nosotros creemos m�s eficiente, bastaba con a�adir la clausula
> ORDER BY y
> eso forzaba la elecci�n adecuada. La verdad es que nunca se me
> ocurio mirar
> que l�gico prefer�a.
>
_____________________________________________________
Forum.HELP400 es un servicio m�s de NEWS/400.
� Publicaciones Help400, S.L. - Todos los derechos reservados
http://www.help400.es
_____________________________________________________
Para darte de baja, env�a el mensaje resultante de pulsar
mailto:[EMAIL PROTECTED]?body=LEAVE
