En cuanto tenga un hueco, revisaré todo lo que apuntas en tu correo. Ya
comentaré los resultados.
________________________________
De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] En nombre de Tellez
Alvarado, Ignacio Andres
Enviado el: miércoles, 26 de marzo de 2008 20:55
Para: forum.help400
Asunto: RE: SQL vs SQL -- curiosidad
Yo tuve un problema similar, y encontramos una solución al problema.
Una consulta SQL sobre varios millones de registros se comportaba muy
lentamente en un ambiente interactivo (por ejemplo SRTSQL), y la misma
consulta
en otro ambiente (ISeries Navegator) era muy rápida, y en un programa
Batch (SQLRPG) la misma consulta era muy lenta.
La rareza se da porque en los diferentes ambientes los parámetros de
ordenamiento de los JOBS son distintos (parámetro SRTSEQ), o al compilar
Un SQLRPG se indicó una secuencia que no era la correcta.
En una sesión interactiva (por ejemplo) el SRTSEQ esta en *LANGIDSHR;
al ejecutar el STRSQL y ejecutar F13, los parámetros de ordenación
Podrían no ser iguales (por ejemplo *HEX). Ahora si me conecto desde
el iSeries Navegator el SRTSEQ es distinto, porque el trabajo servidor del AS400
tiene otra secuencia de ordenamiento.
Estas diferencias de SRTSEQ provocan este comportamiento anómalo en
cada ambiente y hace que las consultas SQL sean eternas.
Solucionamos el problema, regularizando todos los entornos de trabajo
a un valor común y que el idioma de todos los ambientes fuera el mismo.
Otra alternativa es usar *HEX para todos.
Ojala que hayan podido entenderme.
Saludos,
Ignacio T.
________________________________
De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] En nombre de [EMAIL
PROTECTED]
Enviado el: Miércoles 26 de Marzo de 2008 10:18
Para: forum.help400
Asunto: Re: SQL vs SQL -- curiosidad
por curiosidad , ya que estas metido en el tema:
¿ Podrías comprobar cuanto tarda en leer los millones de registros
mediante un programa RPG IV ? . Con SETLL I READE por ejemplo .
Gracias y saludos.
En/na Javier Mora ha escrit:
Hola Alex:
Bueno, a no ser que lo haya creado el sistema, el archivo físico con
los 100 millones de registros no tiene ningún índice, sólo la vía de acceso
creada con el físico (DDS). Lo que apuntas podría ser cierto, incluso si el
sistema creara un índice temporal, pero comprobé después de ejecutar el SELECT
con RUNSQLSTM, QM o RPG, el tiempo de ejecución con STRSQL siendo los
resultados los mismos.
Podrían ser PTFs. Estoy en V5R4 con el nivel 7282 del PTF acumulativo.
El grupo para DB2 UDB está en el 13. Consultaré el link que me indicas.
Sobre el asesor también visitaré la reseña que indicas.
Un saludo,
Javier Mora
________________________________
De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] En nombre de
alex martinez
Enviado el: martes, 25 de marzo de 2008 11:50
Para: forum.help400
Asunto: Re: SQL vs SQL -- curiosidad
Si estás en V5R4 puede que el sistema te haya recomendado un
indice. Es mucho especular, pero puede que durante tu primer intento el indice
no estuviera disponible y en la siguientes consultas ya estaba preparado....
Aunque están apareciendo contínuamente PTFs sobre OSP-DB
PERFORMANCE como por ejemplo
http://www-912.ibm.com/a_dir/as4ptf.nsf/ALLPTFS/MF43280
Sobre el asesor de indices publiqué una entrada sobre esta
novedad en mi blog
http://www.ajut400.com/2007/06/asesor-de-ndices.html
El día 25/03/08, Javier Mora <[EMAIL PROTECTED]> escribió:
Hola a todos:
Esta nota es sólo para exponer una curiosidad que me ha surgido
al utilizar SQL. Os explico.
He construido una sentencia SELECT no muy complicada que toma
datos de cuatro ficheros, dos de ellos con 15 millones y casi 100 millones de
registros. Mi método de trabajo consiste en probar primero los resultados desde
una sesión interactiva de SQL (STRSQL). Después de intentar optimizar en varias
ocasiones la sentencia, desde STRSQL no he conseguido que termine la ejecución
(en todas las ocasiones esperé más de una hora, hasta que cancelé el proceso).
Esta situación me desesperó un poco. En equipos anteriores la
ejecución de trabajos por lotes ha ido siempre más rápida (hablamos de
programas no interactivos). Cogí la misma sentencia SELECT y la ejecuté con el
mandato RUNSQLSTM en batch. ¡Oh, que sorpresa! La ejecución terminó en no más
de un minuto. Como la sentencia SQL la tuve que cambiar para dejar los
resultados en un fichero pensé que podría tener algo que ver. Luego intenté
ejecutar RUNSQLSTM en interactivo y, ¡qué casualidad!, el resultado fue el
mismo (o casi): entre un minuto y dos en ejecutarse.
Hice una prueba más, para disipar alguna duda. Utilicé la misma
sentencia SELECT en QM y los resultados fueron similares.
Finalmente, incluí el SQL en el programa RPG desde donde debía
trabajar con las filas devueltas y su ejecución no fue más allá de los dos
minutos.
¿Es esto sólo una curiosidad? ¿Alguien tiene o se le ocurre una
explicación? Desde mi punto de vista, una sentencia SQL debería ejecutarse a
través de los mismos recursos desde STRSQL o cualquier otra utilidad. ¿Estoy
equivocado?
Un saludo
Javier Mora
__________________________________________________
Forum.HELP400 es un servicio m&#225;s de NEWS/400.
&#169; Publicaciones Help400, S.L. - Todos los derechos
reservados
http://www.help400.es
_____________________________________________________
Para darte de baja visita la siguente URL:
http://listas.combios.es/mailman/listinfo/forum.help400
--
Mi blog sobre as400
http://www.ajut400.com
________________________________
__________________________________________________
Forum.HELP400 es un servicio m&#225;s de NEWS/400.
&#169; Publicaciones Help400, S.L. - Todos los derechos reservados
http://www.help400.es
_____________________________________________________
Para darte de baja visita la siguente URL:
http://listas.combios.es/mailman/listinfo/forum.help400
________________________________
-----------------------------------------------------------------
Notice of Confidentiality: The information transmitted is intended only
for the sender and person or entity to which it is addressed and may contain
confidential and/or privileged material. Any review, e-transmission,
dissemination or other use of, or taking of any action in reliance upon, this
information by persons or entities other than the intended recipient is
prohibited.
If you received this in error, please contact the sender immediately by
return electronic transmission and then immediately delete this transmission,
including all attachments, without copying, distributing or disclosing same.
------------------------------------------------------------------
Aviso de Confidencialidad: Este correo electrónico y/o el material
adjunto es para uso exclusivo del emisor y la persona o entidad a la que
expresamente se le ha enviado, y puede contener información confidencial o
material privilegiado. Si usted no es el destinatario legítimo del mismo, por
favor repórtelo inmediatamente al remitente del correo y bórrelo.
Cualquier revisión, retransmisión, difusión o cualquier otro uso de
este correo, por personas o entidades distintas a las del destinatario
legítimo, queda expresamente prohibido. Este correo electrónico no pretende ni
debe ser considerado como constitutivo de ninguna relación legal, contractual o
de otra índole similar.
------------------------------------------------------------------
__________________________________________________
Forum.HELP400 es un servicio m&#225;s de NEWS/400.
&#169; Publicaciones Help400, S.L. - Todos los derechos reservados
http://www.help400.es
_____________________________________________________
Para darte de baja visita la siguente URL:
http://listas.combios.es/mailman/listinfo/forum.help400
