Hola Jorge y [EMAIL PROTECTED]: Estoy siguiendo esta conversación y me gustaría aportar unos comentarios en base a mi experiencias, estoy abierto al debate y a otras opiniones, ya que lo que aplico en mi caso puede no ser aplicable en otros:
- Consumo de CPU: Aunque no es tu caso, hay que tener en cuenta que el % de consumo de CPU de un trabajo depende de la cantidad de procesadores; por ejemplo un programa que se nos meta en bucle y empiece a consumir el 100% de CPU en un sistema con 10 procesadores solo consumirá como máximo un 10%. - Acceso a disco: Con la potencia de proceso (CPW) los iSeries de hoy dia, donde mas se puede mejorar el rendimiento (suponiendo que el resto es ok) es el la configuración de los discos y en el caso de usar journal (obligado con SQL) se recomienda utilizar una ASP separada y con una protección en mirroring para mejorar el acceso a disco para grabar los cambios en los receptores de diario. También realizar el balanceo (STRASPBAL) y defragmentación (STRDSKRGZ) de los discos periódicamente, así como rgzpfm de los archivos para mejorar su acceso, al menos los mas utilizados y siempre que se acceden secuencialmente si no no vale la pena (creo). - Ciclos de COMMIT: Al usar SQL, estamos utilizando implícitamente ciclos de commit (si no indicamos lo contrario), pero si no indicamos lo contrario al lanzar un UPDATE de una tabla de 200Mregs, solo tendremos un ciclo de commit de inicio a fin. Ventajas: Si cancelamos el proceso el sistema retrotrae automáticamente los cambios y nos deja el archivo como antes de empezar. Desventajas, yo creo que hay más: - Los ciclos de commit de larga duración penalizan mucho el rendimiento del sistema, me parece recordar que en algún proceso se comprobaba que cada vez el trabajo iba mas lento (actualizaba menos registros). - también obtenemos (gratis) un incremento de la ocupación en disco ya que los receptores de diario no se eliminan hasta que como mínimo no tienen acciones pendientes (commit's). También me había pasado en la V5R1 (o V4R5) que si se cancelaba el trabajo al hacer rollback fallaba si había mas de 11 receptores de inicio a fin (existe una ptf). Alternativa: Utilizar el parámetro WITH NC del SQL (no usar commit), o si se lanza con RUNSTMSQL utilizar COMMIT(*NONE) con esto ganaremos velocidad de proceso. Solo una ADVERTENCIA si casca o cancelamos el proceso no hara ROLLBACK y por tanto sol ose debe usar en los casos en que eso no importe. - Sobre el Optimizador de SQL: - El access plan (PRTSQLINF) se reconstruye cada vez que al lanzar el SQL el Query optimizer detecta que ha cambiado el objeto, o tamaño del pool de memoria (por ejemplo), cosa que pasa frecuentemente si tenemos el ajuste automático del sistema activado, y puede decidir utilizar otra vía de acceso (indice) o crear una temporal y eso implica que puede que decida mal. - Que a veces es imposible reproducir un problema con en otro sistema, nos ha pasado que vemos con el Visual Explain, que el SQL decide utilizar una via más larga y al reportarlo al CAS de IBM y enviarles un ejemplo a ellos (Laboratorio) no les pasa y es porque el SQL lo decide en base a un montón de parámetros a veces irreproducibles de un sistema a otros (modelo, procesador, disco, ocupación, memoria,...) En fin nosotros hemos vamos intentando solventar algunos problemas para mejorar el rendimiento de los trabajos, alguno se ha apuntado ya: - Separar el trabajo en varios, para procesar los datos a trozos, con esto se suele ganar mucho tiempo si tenemos un sistema con varios procesadores, a costa de mas control sobre los procesos. - Fijar la memoria asignada a un pool de memoria (para algún subsistema), para que el SQL no reconstruya el plan de acceso cada vez. - En algún caso extremo, eliminar un indice antes de lanzar un proceso, para que el SQL no decida ir por ese, ya que tardara más. - También, si se puede, utilizar la técnica de compartir la vía de acceso, esto incrementa el rendimiento cuando se abren y cierran muchos archivos en los trabajos, ya que al sistema se cuesta mucho hacer el open/close de los archivos. En fin ahora mismo no se me ocurren más cosas, espero que os sirva, al menos para pasar el rato haciendo pruebas (si podéis). Saludos. 2007/2/28, Jorge <[EMAIL PROTECTED]>:
El iSeries es un modelo 810 con un procesador 2.466 y con 1.020 CPW en Batch, 6 G. de RAM y 12 discos con un total de 705 G., con V5R2M0 con PTF's de sistema TL06080 y con grupo de PTF's SF99502 y la última PTF SI12799. La máquina está al 80% de ocupación. La consulta consiste en un simple Select con una sumarización de campos y una selección de unas marcas lanzada por batch con un SBMJOB de un RUNSQLSTM. En el momento de su ejecución la máquina estaba por debajo del 10% de CPU. Como ya he indicado, el Visual Explain no me propone ningún índice que no tenga ya la tabla. Saludos. -----Mensaje original----- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] nombre de Cubero, Rafael (R.) Enviado el: miércoles, 28 de febrero de 2007 10:33 Para: forum.help400 Asunto: RE: Optimizar lecturas en DB2 UDB Como estais haciendo la consulta, por programa? Interactivo o batch? De ser asi, cuando el programa se creo y se paso por primera vez, el fichero estaba vacio o con pocos reg.? Dame mas informacion, nosostros hemos tenido que bregar muchisimo con estos temas, por cierto tienes que estar a la ultima en PTF's de DB. Saludos. Rafael -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jorge Sent: 28 February 2007 09:50 To: Forum. Help400 Subject: Optimizar lecturas en DB2 UDB Buenos días: Ya se que es un tema recurrente pero me interesan vuestras experiencias en el tema: Estamos intentando optimizar la obtención de una serie de datos de una tabla y no conseguimos unos tiempos razonables (desde nuestro punto de vista). La máquina sobre la que realizamos las consultas tiene versión 5 release 2. La tabla sobre la que lanzamos las consultas tiene 195.000.000 de registros. El Visual Explain no sugiere ninguna via de acceso adicional a las que ya tiene. La consulta la realizamos para todo un año, teóricamente los registros que se analizan deben ser más de la mitad. Por raro que parezca, cuando exportamos la información a una tabla en pc, los registros parecen ser leídos mucho más rápido. Por lo que se nos plantea la idea de volcar la información a una DB en un PC y realizar las consultas directamente sobre éste. ¿Alguien lo ha probado de esta forma?. Gracias. Jorge __________________________________________________ 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
-- Martí Riera
__________________________________________________ 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
