por ejemplo , READE de tres campos clave .
Y si no es molestia READ del fichero entero ..
Saludos y Gracias.
En/na Javier Mora ha escrit:
¿Qué atrevido eres? ;-)
¿El READE de cuantos campos de clave? ¿De registros del principio, en
medio o del final?
De todas formas, al no tener más vías de acceso que la del archivo
físico, creo que irá muy rápido. Haré algunas pruebas.
------------------------------------------------------------------------
*De:* [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] *En nombre de
[EMAIL PROTECTED]
*Enviado el:* miércoles, 26 de marzo de 2008 14: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]
<mailto:[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
------------------------------------------------------------------------
__________________________________________________
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
__________________________________________________
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
