Hacer un SQL trace (traza de SQL) significa registrar y analizar las consultas SQL que se están ejecutando en el sistema SAP — especialmente desde programas ABAP — para poder:
-
Detectar cuellos de botella de rendimiento.
-
Ver cómo el ABAP se traduce en sentencias SQL en la base de datos.
-
Saber qué datos se están solicitando y cómo se acceden.
¿Para qué sirve un SQL trace?
¿Para qué lo usamos? Ejemplo
| Optimizar performance |
¿Por qué un SELECT tarda tanto? ¿Hace full table scan? |
| Debug de acceso a BD |
Ver si una consulta trae los datos esperados. |
| Diagnóstico de errores |
Detectar errores de acceso, joins incorrectos o condiciones mal aplicadas. |
¿Cómo se hace un SQL Trace en SAP?
Se hace desde la transacción ST05 (la herramienta estándar para tracing):
Pasos:
-
Ir a transacción ST05.
-
Elegir "SQL Trace" → activar para tu usuario (o el que quieras analizar).
-
Ejecutar el programa, transacción o función que quieras analizar.
-
Volver a ST05 y detener el trace.
-
Hacer clic en Display Trace para analizar los resultados.
¿Qué muestra un SQL trace?
-
Sentencias SQL ejecutadas (ej. SELECT, INSERT, UPDATE)
-
Tablas accedidas
-
Tiempo de ejecución
-
Filas leídas
-
Índices utilizados
-
Plan de acceso de la base de datos
Ejemplo de análisis típico:
Vemos que una sentencia SELECT lee 10,000 registros, pero solo necesita 1.
Solución: agregar una cláusula WHERE más específica o usar SELECT SINGLE.
Importante:
-
ST05 solo traza consultas SQL estándar (Open SQL).
-
No muestra lo que se ejecuta directamente con Native SQL o AMDP (para eso hay herramientas como PlanViz o HANA Studio).
-
Si estás en un entorno HANA, también puedes usar HANA Performance Trace, desde HANA Studio o DBACOCKPIT.
Resumen:
Concepto Explicación
| SQL Trace |
Registro detallado de consultas SQL lanzadas por ABAP. |
| Transacción |
ST05 |
| ¿Para qué sirve? |
Optimizar, depurar, entender el comportamiento del acceso a datos. |
¿El ORDER BY es importante en SAP HANA?
Sí, mucho más que antes.
En SAP HANA, si haces un SELECT sin ORDER BY, no hay garantía del orden de los registros que devuelve.
Esto puede causar comportamientos inesperados en programas que asumen un orden "implícito", que antes se respetaba en otras bases de datos (como Oracle o MaxDB), pero no en HANA.
¿Por qué ocurre esto?
SAP HANA es una base de datos in-memory columnar que optimiza el rendimiento y puede paralelizar las consultas.
Eso significa que:
-
Puede traer los registros en cualquier orden.
-
El orden puede cambiar entre ejecuciones.
-
La única forma de asegurar el orden es usando ORDER BY.
Ejemplo práctico:
SELECT * FROM zclientes INTO TABLE @DATA(lt_clientes).
En bases antiguas, esto podía traer los datos ordenados por la clave primaria (por costumbre, no por diseño).
En SAP HANA eso ya no se garantiza.
Si el programa luego hace algo como READ TABLE lt_clientes INDEX 1, podrías estar leyendo el "primer" cliente... pero no necesariamente el correcto.
¿Cuándo debes usar ORDER BY en SAP HANA?
Situación
¿Usar ORDER BY?
Motivo
| Mostrar datos en pantalla o reporte |
Sí |
Para asegurar presentación consistente |
| Seleccionar el primer registro (INDEX 1) |
Sí |
Garantizar que es el deseado |
| Lógica que depende del orden (fechas, montos, etc.) |
Sí |
Evitar errores funcionales |
| Procesos batch donde el orden no importa |
Opcional |
Si el orden es irrelevante, puede omitirse |
En migraciones a SAP HANA:
-
Es muy común encontrar bugs por SELECT sin ORDER BY.
-
Herramientas como SAP Code Inspector o ABAP Test Cockpit (ATC) ayudan a detectar esos casos.
-
SAP recomienda revisar y corregir todos los SELECT críticos.
Recomendación general:
"Siempre que el orden importe, debes usar ORDER BY. Nunca asumas un orden sin declararlo explícitamente."