✒️El análisis y la optimización con SAP HANA

1) ANALISIS Y OPTIMIZACION CON SAP HANA.

- Que herramientas usar para optimizar códigos ABAP existentes o generar de cero, asi potencial paradigma code pushdown.

- Herramientas:

i) Trace SQL ST05: Optimiza SELECT.

ii) Análisis tiempo ejecución ABAP por transacción SAT: Por sección "Tips and trick" se compara performance.

iii) Verificación ampliada código por transacción SLIN: Verifica estática del código.

iv) Chequear con inspector de código por transacción SCI: Se comprueba performance, seguridad, sintaxis, etc.

v) Test cockpit de transacción ATC: Es similar a SCI, pero con mejoras.

vi) Registro estadística con transacción STAD : Entrega visión simple de tiempo BD.

vii) Análisis de transacción por transacción ST12 : Herramienta que combina transacciones STAD, SAT, ST05.

viii) Análisis errores transacción ST22 : Información sobre DUMP solamente errores.

A partir de ABAP 7.4 se agregan nuevas:

ix) Monitor SQL por transacción SQLM : Supervisa producción, analiza las sentencias SQL y entrega info de tiempo ejecución. La memoria cache entrega información sobre declaración SQL. Esta info de cache, + la del ABAP y la ejecución se ve en este monitor.

x) Transacción SWLT : Combina datos de SQLM con resultado de análisis de código, se puede hacer optimizaciones.

2) ANALISIS DEL CODIGO ABAP.

i) Con transacción SCI se ve que partes del código se pueden mejorar para SAP HANA.

ii) Entrega mensajes con prioridades, errores, warning e información.

iii) Pueden ocurrir falsas alarmas, así mejor insertar comentarios especiales en código.

iv) SAP no permite escanear código estándar con CODE INSPECTOR.

v) Con CODE INSPECTOR permite :

a) Se chequea objetos o conjunto de objetos para ver su rendimiento, seguridad, sintaxis y convenciones de nombres.

b) Se indicar que con CHECK VARIANT (variante de verificación) vea ciertos objetos.

c) Retonan mensaje de error, adventencia o información.

d) VARIANTE DE VERIFICACIÓN: Define las reglas que se realizarán y configuración de comprobaciones.

e) CONJUNTO DE OBJETOS: Son los objetos a verificar.

f) INSPECCIÓN EN CONTEXTO DE INSPECTOR DE CÓDIGO: Es una comprobación que deben aplicarse a que objetos. Combina variante de comprobación y conjunto de objetos.

g) VARIANTE VERIFICACIÓN LOCAL Y GLOBAL: Los globales para que todos los usuarios la usen y locales a usuarios específicos. La variante global daba por SAP se llama DEFAULT. Si creamos una variante DEFAULT local para un ID, el sistema usará esa como global y local.

h) Al ejecutar la transacción SCI, verificar que venga la global DEFAULT, presionar visualizar y ver que este global.

i) Para generar un local, se debe copiar la DEFAULT global como local y asignar nombre.

j) Se modifica la nueva y se debe abrir carpeta "PROGRAMMING CONVENTIONS".

k) Hay 5 alternativas, se debe tildar la 1,2 y 4. Grabar.

l) Desde SE38 seleccionar code inspector.

m) Crear variante de verificación en CHECK VARIANT. Esta nueva variante se tildan las selecciones y check que genero el resultado de la inspección.

n) En los atributos se ven las convenciones para nombres.

o) Se tildan General Checks, programming conventions.

p) Se graba variante.

q) Se debe crear un OBJECT SET. Se debe destildar los objectos de selección y tildar PROGRAM, donde se incluye el programa a inspeccionar. Grabar.

r) Se debe crear una nueva INSPECTION,en OBJECT SET se agrega el nombre y en CHECK VARIANT el nombre de la CHECK VARIANT. Grabar.

s) Se ejecuta y vemos resultado.

t) Arreglar programa, no olvidar PRETTY PRINTER.

2.1) VERIFICACIONES RELEVANTES AL MIGRAR A SAP HANA.

1) La prioridad de migrar es que no exista problemas funcionales, cancelación de pgm DUMP y cambios no deseados de aplicación.

2) Gracias a compatibilidad y portabilidad del código ABAP, no es necesario ajustar programas.

3) NATIVE SQL Y HINT DE BD: Se debe cambiar si hay SQL Nativo en BD.

%_HINT ORACLE 'PARALLEL(V_EQUI , 10)'.

Esto es tipico de ORACLE, no funcionaran en HANA, para localizarlo usar en Inspector de código Uso de la Interface ADBC y sentencias críticas.

4) COMPORTAMIENTO DEL SORT : Los SORT en SELECT de BD columnares deben tener cláusula ORDER BY, sin esto se devuelven datos desordenados. Al no utilizarlo, deben ser ordenados posteriormente en programa con SORT.

SELECT * FROM mara INTO TABLA ti_mara

ORDER BY matnr DESCENDING.

5) ADIOS A LA TABLAS CLUSTER Y POOL :

i) Al migrar a HANA las tablas cluster y pool son convertidas en tablas transparentes en forma automática, no se requieren cambios en las aplicaciones que las ocupan.

ii) Al usar OPEN SQL no se debe confiar en ordenamiento, clave primaria.

iii) Se recomienda poner ORDER BY en SELECT o hacer SORT en pgm

iv) En INSPECTOR DE CODIGO, categoria PROGRAMACION ROBUSTA permite encontrar SELECT sin ORDER BY.

2.2) VERIFICACIONES RELEVANTES AL OPTIMIZAR PARA SAP HANA :

a) USO INSEGURO DE FOR ALL ENTRIES : Asegurarse que tabla no este vacia. No usar SELECT dentro de otro SELECT, mejor usar JOIN.

b) BUSCAR LAS SENTENCIAS FOR ALL ENTRIES PARA TRANSFORMARLAS EN UNIONES : Mejor traspasar a JOIN.

c) DECLARACIONES SELECT QUE OMITEN BUFFER DE TABLA : Se debe activar en la creación de tabla, SAP HANA lo utiliza. Se debe validar al migrar si lo tiene activo por cada tabla.

d) INSTRUCCIONES PROBLEMÁTICAS SELECT: No leer columnas o campos que no se necesitan.

e) BUSCANDO SELECT EN LOOP EN SUBRUTINAS :

i) El problema rendimiento es por muchos acceso sucesivos a tabla.

ii) Esto ocurre con SELECT dentro de un LOOP.

f) EXIT/CHECK EN SELECT...ENDSELECT :

i) Un exit de un SELECT..ENSELECT hace que se hallan leido muchos registros innecesarios, esto por las lecturas son por bloque.

ii) Se debe usar CHECK después de SELECT.

iii) Mejor utilizar WHERE y el SELECT..ENSELECT sólo para tablas de opciones y pequeñas.

Agradecimiento:

Ha agradecido este aporte: Franklin Parra