
Hoy voy a resumir el punto de cómo podemos apuntar para lograr el mejor rendimiento para una vista de consulta y cálculo en HANA 2.0 SPS 03 y la versión del epílogo con escenario.
Hay pocas formas en las que podemos analizar el rendimiento y ajustarlo para obtener uno óptimo del modelo:
1. Usando EXPLAIN_ PLAN (disponible en HANA Studio, WEB IDE y BAS) (incluyendo HANA 1.0 XSC y HANA 2.0 XSA): En el editor SQL del Explorador de base de datos en Web IDE o BAS, ejecute la siguiente consulta (para la vista de Cálculo, extraiga la consulta subyacente) para verificar el PLAN DE EXPLICACIÓN.
-- Syntax EXPLAIN PLAN SET STATEMENT_NAME = 'TEST_SQL' FOR <SQL-QUERY> --
EXPLAIN PLAN SET STATEMENT_NAME = 'TEST_SQL'
FOR(
Select C.EMP_ID C.SALES_AMMOUNT from SALES_ITEAM C
LEFT OUTER JOIN ( SELECT D.EMP_ID,D.ADDRESS FROM EMPLOYEE D)
ON C.C.EMP_ID=D.EMP_ID
WHERE C.SALES_AMMOUNT > 1000
GROUP BY SALES_AMMOUNT);
si una consulta está disponible en M_SQL_PLAN_CACHE y quieres ver el EXPLAIN_PLAN Vista de entonces, primero tenemos que encontrar la ID del plan de ID usando la consulta a continuación:
SELECT
PLAN_ID
FROM "M_SQL_PLAN_CACHE"
WHERE SCHEMA_NAME = 'PLB_TEST'
AND STATEMENT_STRING LIKE '%/*literal*/ Select C.EMP_ID C.SALES_AMMOUNT'
ORDER BY LAST_PREPARATION_TIMESTAMP DESC;
Luego, utilizando la identificación del plan, busque el plan de compilación para la consulta:
EXPLAIN PLAN SET STATEMENT_NAME = 'TEST_SQL'
FOR SQL PLAN CACHE ENTRY '<PLAN_ID>';
Usando el resultado a continuación, puede analizar la planta generada y su fila y otros parámetros:
El siguiente diagrama proporcionado por SAP utilizando el siguiente enlace de referencia:
Ahora, usando la sugerencia, puede cambiar la ejecución del plan de subconsultas y el motor de ejecución.
SELECT * FROM T1 WITH HINT( USE_OLAP_PLAN );
Nota : Todo este tiempo y resultado es un valor estimado, no valores ejecutados y los detalles del plan de explicación generados durante la construcción.
2. Usando Rastreo de SQL (incluyendo HANA 1.0 XSC)/Analizar código SQL Script (HANA 2.0 XSA) :
SQL Trace es muy útil para el ajuste del rendimiento de los procedimientos que tienen múltiples declaraciones en línea. Puede rastrear fácilmente qué declaración está tomando mucho más tiempo y menos tiempo y, de acuerdo con eso, puede dividir la declaración en varias declaraciones para optimizar el rendimiento.
A. Para habilitar SQL Trace, ejecute la siguiente consulta:
ALTER SYSTEM ALTER CONFIGURATION ('indexserver.ini', 'System' ) SET ('sqltrace', 'query_plan_trace') = 'on' WITH RECONFIGURE;
B. Ejecutar el trámite o Consulta.
C. Instale SAP HANA SQL Trace Analyzer y configúrelo en Cockpit y podrá comprobar el seguimiento.
Esta función está disponible en el entorno HANA 1.0 XSC.
HANA XSA 2.0 también tiene el mismo tipo de herramienta que utiliza el explorador de base de datos de SAP HANA “Analizar código SQL Script “Podemos comprobarlo.
3. Modo Health Check (HANA XSA 2.0 en adelante):
Cuando abre una vista de cálculo en el modo de editor, tendrá un modo de verificación de estado que es un procedimiento integrado que evalúa el modelo de cálculo y le proporciona una pista sobre qué acción puede optimizar la consulta, como la cardinalidad u otra.
En la consola SQL, ejecute los procedimientos a continuación para verificar las sugerencias.
CALL CHECK_ANALYTICAL_MODEL(”,’SCHEMA1′,’CV_DEMO_TEST’,?);
CALL CHECK_ANALYTICAL_MODEL('','SCHEMA1','CV_DEMO_TEST',?);
CALL "SYS"."CHECK_CALCULATION_VIEW"(
ACTIONNAME => ''/*<NVARCHAR(64)>*/,
SCHEMA_NAME => ''/*<NVARCHAR(256)>*/,
VIEW_NAME => ''/*<NVARCHAR(256)>*/
)
El siguiente es un resultado de muestra de la ayuda de referencia de SAP:
Trabaje de acuerdo con la salud y solucione el problema.
4. Uso de la pestaña Análisis de rendimiento en Web IDE (AHANA XSA 2.0 SPS02 en adelante):
Este modo lo he usado mucho para poner el rendimiento en Track.
En Web IDE para una vista de cálculo, hay un modo de análisis de rendimiento que proporciona la pista que encontró después del análisis del plan y mejora el rendimiento.
En el modo de análisis de rendimiento, la información disponible sobre las tablas de unión, las particiones de tablas y otra información, lo que le ayuda a analizar su vista de cálculo y afinarla.
.
5. Usando Plan Viz (HANA XSC HANA studio) o SQL Analyzer con SAP HANA Cloud en (BAS):
Al usar esta herramienta, podemos ver qué nodo está devolviendo qué cantidad de fila y qué nodo está causando el problema. Usando HINT o podar la combinación interna debajo del nodo que causa el problema, podemos obtener un mejor rendimiento para la consulta.
Para poner el archivo de plan Viz .PLV en Analizador SQL con SAP HANA Nube, necesitamos generar un archivo .PLV desde el Explorador de base de datos y ponerlo/importarlo en el analizador SQL.
Hay un buen blog que describe cómo importar el archivo en el analizador en detalle:
Ahora comencemos si vemos mientras analizamos el plan a través del analizador SQL/Plan Viz que un nodo está devolviendo una gran cantidad de filas que causan un rendimiento lento. Esto se puede averiguar después de ejecutar el SQL analizador/Plan Viz plano interior abierto -> lógico.
Paso 1 : Encuentre el operador dominante y el posible reductor de clave:
El operador dominante es el nodo que devuelve la gran cantidad de datos que causan el rendimiento lento y el posible reductor de clave será el nodo superior que redujo las filas y devolvió una pequeña cantidad de filas y distinguibles.
Analicemos el escenario utilizando el plan proporcionado por SAP en el siguiente enlace:
Aquí, si ve que el nodo Agrupar por/Agregación es el operador dominante y ningún 4 podría ser el posible reductor clave, ya que reduce significativamente la fila de retorno.
Nota: la nota 3 no parece ser un posible reductor de clave, ya que no reduce la fila de manera significativa.
Paso 2: empuje hacia abajo el posible nodo reductor de clave: En este escenario debajo del nodo de operador dominante usando HINT.
Aquí si usamos JOIN_THRU_AGGR para empujar hacia abajo el nodo Join 4 (unión interna) empujará hacia abajo:
Ahora el Plan de resultados se verá como a continuación. La agregación o GROUP BY se mueve en el TOP.
Paso 3: tenga en cuenta que el paso 2 aplica la sugerencia que siempre no funciona y no da como resultado una precisión. En este escenario, reducimos el subconjunto mediante la combinación interna con otra tabla que existe en otra rama y se unió en los nodos superiores.
En este caso, tomamos T1 del otro lado y lo unimos con T2 en la columna de búsqueda # 2
Nota: diagrama proporcionado por SAP en el siguiente enlace:
Espero que facilite su trabajo en cualquier situación en la que necesite optimizar el rendimiento.
Calle Eloy Gonzalo, 27
Madrid, Madrid.
Código Postal 28010
Paseo de la Reforma 26
Colonia Juárez, Cuauhtémoc
Ciudad de México 06600
Real Cariari
Autopista General Cañas,
San José, SJ 40104
Av. Jorge Basadre 349
San Isidro
Lima, LIM 15073