Presentación Taller Herramientas Rendimiento DB2 en IBM i y Genexus generando contra RPG y Java. Contiene recomendaciones de como escribir las consultas en Genexus en un entorno específico en ETAPA EP

1. Xavier Espinoza Luna
Marzo 2019

2. Agenda
 Componentes de software
 Generación de programas en Genexus
 Arquitectura del DB2 para IBM i
 Herramientas de monitoreo
 Recomendaciones al ejecutar y programar consultas
 Documentación de referencia y enlaces de interés

4. ¿ Por qué se planteó el Taller ?
 El sistema IBM i aloja el
procesamiento de gran parte de los
datos empresariales de ETAPA EP
desde hace algunas décadas debido a
su efectividad, el bajo nivel de
administración y la confianza de la
plataforma en procesar cargas de
trabajo.
 A pesar de que la plataforma es
autoadministrable, autoajustable,
fácil de usar y fácil de mantener,
conocer de herramientas de
monitoreo y análisis de rendimiento
es ventajoso.

5. ¿ Qué pretende el Taller ?
 La mejora de rendimiento del sistema es un tema
demasiadamente amplio y considera desde el diseño de las
aplicaciones hasta un monitoreo constante de la ejecución de las
mismas.
 Hacer una introducción básica de la arquitectura de la base de
aplicaciones nativas y cliente/servidor.
 Hacer una introducción básica de la arquitectura de la base de
datos.
 Hacer una introducción de las herramientas y opciones de
monitoreo existentes con el fin de propiciar mejoras en las
consultas.
 Hacer recomendaciones básicas al momento de realizar la
codificación tanto de aplicaciones como en consultas.

7. DB2 para IBM i
 DB2 es la base de datos embebida dentro del IBM i
 Tres bases de código de DB2 basado en la historia de
los sistemas, en la arquitectura y en el sistema
operativo.
 DB2 para i (IBM i, System i, IBM i, AS/400)
 DB2 para z (System z, zSeries, S/390)
 DB2 para luw (Linux, UNIX, Windows, System p, System
x)

8. DB2 para IBM i

9. DB2 para IBM i
 Ventajas de la plataforma
 La “i” proviene de sistema integrado
 La base de datos parte del sistema operativo
 Autónoma y autoadministrable
 Muchas aplicaciones legada en lenguajes nativos (COBOL, RPG)
contra los mismos datos junto a aplicaciones modernas (.Net, Java,
PHP).
 Trabajo a bajo nivel
 Una sola base de datos con múltiples interfaces de acceso
 Nativo (CRTPF, CLRPF, DDS)
 SQL (Embebido, ODBC, JDBC, CLI)
 Dos tipos de índices (Radix o Arbol Binario/Vector Codificado)
 Tablas particionadas, Consultas Materializadas
 Procesamiento simétrico (DB2 Symmetric Multiprocessing)

10. Interfaces de acceso
Aplicaciones
generadas en RPG
utilizan el acceso nativo
sobre la base de datos
(READE, SETLL,
CHAIN, OPNQRYF). La
optimización del
rendimiento depende
del diseño y la forma de
acceder a los datos.
Aplicaciones en .Net o
Java utilizan el acceso SQL
sobre la base de datos. La
optimización del
rendimiento depende de
como los programas y
consultas se ingresan a los
datos y de la asistencia de la
base de datos.
Consultas Query/400
utilizan el acceso nativo y
tienen cierto nivel de
optimización dentro del
sistema operativo.

11. Genexus
 Generador de programas a partir de un conjunto común de
fuentes de conocimiento (Knowledge Manager) y lenguaje
neutral.
 En ETAPA EP se generan programas en RPG III, JAVA y C# que
usan la base de Datos DB2 contenida en un servidor IBM i.
 La arquitectura de las aplicaciones generadas son las clientes :
 Entorno WIN : Pantalla Verde en donde la interfaz de usuario,
acceso a datos, lógica y consultas lo resuelve el propio IBM i.
 Entorno WEB : Orientado a Navegador en donde corre la interfaz de
usuario interpretado por el PC (HTML, JS), la lógica y el acceso a
datos y consultas las realiza el Application Server (IIS) y el DB2 es
repositorio de datos o puede ejecutar lógica que esta fuera de lo que
controla el GX (Procedimientos Almacenados, Triggers, etc).
 Existen procesos independientes que corren en Windows (C#) y
dentro del sistema IBM i (Java) para modificar información.

13. Generación en RPG
 RPG Nativo, usando para la creación de bases de datos
hojas DDS (Data Definition Sheets) en donde se definen
“estructuras de registros” para obtener datos.
 Tanto las tablas base como los índices son definidos
mediante “estructuras de registros” usando DDS. También
las claves primarias.
 Puede usarse SQL dentro de RPG así como la activación de
restricciones (FK PK NULL) pero Genexus no genera a ese
nivel o no aprovecha el generador RPG de dichas
características estándar.
 En la lógica de obtención de datos dentro del programa
RPG generado se utilizan las “estructuras de registro”.

14. Generación en RPG
 En Genexus se advierte la creación de índices, por cuanto es
más eficiente leer una “estructura de registro” de un índice
construido que formar al vuelo la información.
 Si no existe un índice o este no se ha creado, el
ordenamiento o selección e información se utiliza el
comando OPNQRYF quien genera el “query” o “consulta”.
 Las uniones de tablas o el acceso a las tablas extendidas,
Genexus realiza “manualmente” la unión y no utiliza
OPNQRFY para ello.
 OPNQRFY es un API para creación de consultas de forma
dinámica y similar a lo que realiza SQL. Se ejecuta en el
CQE o Classical Query Engine.

15. Generación en RPG
 En Genexus RPG el programador utiliza el camino
necesario para acceder a los datos o en su defecto
empleará OPNQRFY.
 La optimización del rendimiento se basa en utilizar las
recomendaciones de escritura del código en Genexus
interpretando el Navigation View y en la destreza del
programador (cuantos accesos hace para obtener la
información, por que medio o índice, etc).

16. Generación en Java o C#
 Utiliza el estándar SQL para poder manipular los datos.
 La creación de la base de datos se emplea sentencias DDL
de creación (CREATE TABLE, CREATE INDEX).
 En ciertas bases de datos genera secuencias (CREATE
SEQUENCE)
 Para uniones utiliza las sentencias JOIN estándar de SQL.
 Emplea ciertas construcciones de la base de datos (más
optimo) según como se codifique.
 Puede activarse la integridad referencial en toda la base de
datos (FK, PK, Nulos).

17. Generación en Java o C#
 La optimización de las consultas se basa en la destreza
del programador para obtener la información y en
emplear las herramientas de rendimiento del servidor
IBM i.
 A diferencia de RPG el “Gestor de la Base de Datos” es
quien decide por que camino ir para obtener la
información. Obviamente al “Gestor” hay que indicarle
las opciones y este también decide por donde ir o
sugiere que se debe hacer para la mejora respectiva.
 Se deben emplear las opciones existentes en el servidor
para ajustar las consultas.

19. Arquitectura de
Procesamiento de
consultas y
aplicaciones
Aplicaciones
generadas en RPG
utilizan el acceso
nativo sobre la base de
datos (READE,
SETLL, CHAIN).
Aplicaciones en .Net o Java utilizan
el acceso SQL sobre la base de datos.
Consultas
Query/400 -
OPNQRYF utilizan
el acceso nativo y
tienen cierto nivel
de optimización
dentro del sistema
operativo (CQE).

20. Optimizadores de Consultas
 Classic Query Engine
(CQE): procesa las
peticiones provenientes
de interfaces no SQL
(Query/400,
QPNQRYF). Todas las
consultas procesadas en
el componente clásico.
 SQL Query Engine
(SQE): procesa las
peticiones basadas en
SQL.

21. Esquema de Procesamiento de
consultas
 Fases de ejecución de una consulta (Query/SQL):
 Validación de la consulta
 Validación de la petición realizada
 Validación de planes existentes (Cache de Consultas)
 Creación de estructuras internas de la consulta
 Despacho de la consulta
 Determinar que componente de optimización (CQE/SQE) completará el proceso.
 Optimización de la consulta
 Escoger el acceso más eficiente los métodos de proceso.
 Construir el plan de acceso
 Ejecución de la consulta
 Construir las estructuras que utilizará el cursor
 Construir estructuras temporales si son necesarias
 Construir y activar el cursor
 Generar la información

22. Características del Optimizador
 El “Optimizador” de consultas en la base de datos DB2
para IBM i está basado en una optimización basada en
costo.
 El “costo” es definido como tiempo estimado que toma
en ejecutarse una petición
 El “costeo” de planes se refiere a la comparación de un
grupo de algoritmos y métodos para encontrar el plan
más rápido y reducir accesos a disco.
 El “Optimizador” tiene la habilidad de reescribir la
consulta.

23. En resumen
 El acceso nativo desde los programas RPG no se beneficia
del optimizador. Depende de como se escribe y se diseña el
programa.
 El optimizador clásico se dispara únicamente en consultas
Query/400 y OPNQRFY.
 El acceso SQL y Query/400 utiliza el componente de
optimización de consultas de la base de datos.
 El optimizador SQL se dispara para consultas SQL.
 El desarrollo y cambios a futuro se realizan sobre el
optimizador SQL, que provee una serie de características
como Estadísticas, Index Advisor, Visual Explain que se
explotan desde el IBM i Access Client.

25. Herramientas de Monitoreo SQL
 Asesor de Índices
 Ante memoria de Planes
SQL
 Instantáneas de ante
memoria de Planes SQL
 Supervisores de eventos de
ante memoria de planes
SQL
 Visual Explain
 Supervisores de
rendimiento

26. Herramientas de Monitoreo SQL
 Explicación demostrativa

28. Recomendaciones para consultas
 Evitar tomar en el SQL los nombres de índices. El DBMS volverá a
reescribir la consulta. En algunos casos utilizará el módulo CQE para
ejecutar la consulta no beneficiándose de las nuevas opciones del
SQE. Esto para el caso de RPG usando OPNQRFY.
 Evitar usar select *. En primera instancia se selecciona información
innecesaria. Al definirse todas las columnas no puede el optimizador
encontrar una ruta alterna (p.e Índice) y no podrá ejecutarse más
rápidamente la consulta.
 Evitar usar funciones o conversiones de datos. Una comparación debe
hacerse en base al mismo tipo de dato, misma escala y misma
precisión. El optimizador encontrará más fácilmente un índice en vez
de recuperar todos los datos.
 Evitar usar expresiones numéricas o cálculos dentro del select. El
optimizador ejecutará la operación sobre todos los datos sin
considerar un posible índice existente.

29. Recomendaciones para consultas
 Construir índices adicionales en base a su estadística
de utilización. Utilizar Index Advisor.
 Construir índices basados en Vector Codificado
dependiendo del tipo de consulta que se requiere
hacer y el nivel de actualización de datos. Se utiliza
para optimizar consultas cuando un campo tiene
pocos valores posibles o baja cardinalidad en
comparación a la cantidad de registros (p.e Estados
de un registro).
 Construir vistas materializadas o tablas particionadas
para mejorar la rapidez de acceso a los datos.

30. Recomendaciones Genexus
Por que índice va a realizar
la consulta
Que condición aplica
sobre el índice (WHERE
- CHAIN)
Sobre los datos recuperados
que búsqueda realiza
Se aplica optimizaciones de ser
el caso. No relevante en RPG.

31. Recomendaciones en Genexus RPG
 En lo posible indicar un índice de lectura que sea
relevante para el proceso. Si no se especifica un índice
Genexus tomará por defecto el índice principal de la tabla
base y sobre todos los datos ejecutará las búsquedas.
 Evitar usar funciones o conversiones de datos dentro de
los argumentos de un for each. Genexus recuperará los
datos del índice o tabla base y sobre aquellos ejecutará las
condiciones.
 Debe validarse según la necesidad el utilizar opciones
dentro del DB2 como por ejemplo JOINS a nivel de RPG,
vistas materializadas y particionamiento.

32. Recomendaciones en Genexus RPG
 Estar atento a los mensajes de especificación
 Cuando se hace una navegación completa de una tabla para
recuperar un solo dato o un grupo de datos (Navigation
filters: Start from: FirstRecord Loop while: NotEndOfTable)
 Cuando se hace un join a nivel cliente (Join location:
Client).
 Cuando una condición dentro de un for each pasa de
“Conditional constraint” a “Standard constraint”
 Considerar que elementos van en “Constraint” que implican
que se leyó por algún índice y luego de ese grupo de datos
recuperado por índice se aplican los “Constraint”

33. Recomendaciones en Genexus C# o
Java
 En lo posible hacer la que base de datos responda a las
peticiones de sumatorias, conteos, etc.. Para ello debe
usarse las optimizaciones creadas dentro de la herramienta
(http://wiki.genexus.com/commwiki/servlet/wiki?26286,F
or+Each+Optimizations,). Las optimizaciones disparan el
SQL correspondiente en la base de datos que es mucho
mejor que si se desarrolla en el lenguaje destino.
 Considerar que el hacer referencia de atributos
relacionados entre distintos datastores hará que los joins se
hagan a nivel de cliente.

34. Generación en Genexus
 Diagrama E-R

35. Generación en Genexus
 For each sin order

36. Generación en Genexus
 For each con order

37. Generación en Genexus
 For each con order pero con función en el criterio de
búsqueda

38. Generación en Genexus
 For each con order y en criterio de consulta con LIKE

39. Generación en Genexus
 For each sin order

40. Generación en Genexus
 For each con order

41. Generación en Genexus
 For each con order

42. Generación en Genexus
 For each sin order

43. Documentación de referencia y
enlaces de interés
 IBM DB2 for i indexing methods and strategies
(https://www.ibm.com/partnerworld/wps/servlet/RedirectServlet?cmsId=stg_
ast_sys_wp_db2_i_indexing_methods_strategies&attachmentName=ibm_db2_
for_i_indexing_methods_and_strategies.pdf)
 System i Database Performance and Query Optimization Version 6 Release 1
(https://www.ibm.com/support/knowledgecenter/ssw_ibm_i_73/rzajq/rzajqp
df.pdf)
 IBM i Technology Updates
(https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/w
iki/IBM+i+Technology+Updates/page/DB2+for+i+-+Technology+Updates)
 Blog de DB2 en i (http://db2fori.blogspot.com/)
 DB2 Performance https://www.youtube.com/watch?v=sW1iN3Yd6wk
 DB2 for i SQL
http://www.ibm.com/support/knowledgecenter/ssw_ibm_i_61/db2/rbafzintro.
htm
 http://www.lab400.com/Faster-Better-Queries.asp

44. Documentación de referencia y
enlaces de interés
 Libros Rojos de IBM (http://www.ibm.com/redbooks)
 Advanced Functions and Administration on DB2
Universal Database for IBM i (SG24-4249-03)
 DB2 Universal Database for IBM i Administration The
Graphical Way on V5R3 (SG24-6092-00)
 Preparing for and Tuning the SQL Query Engine on DB2
for i5/OS (SG24-6598-01)
 SQL Performance Diagnosis on IBM DB2 Universal
Database for IBM i (SG24-6654-00)
 DB2 UDB for AS/400 Visual Explain