Por lo que veo, ya has reportado un Incidente de Soporte, el cual está siendo investigado por el Equipo de Desarrollo. Por favor, continúa en el incidente.
Avalados por :
¡Hola a todos!
El Query del Panel de Control ha estado funcionando bien en HANA 1.0 y se está ejecutando con 88 GB desde la Consola SQL de HANA Studio. El mismo Query del Panel de Control se ejecutó desde la aplicación Spotfire y está funcionando, pero después de un tiempo falla con el siguiente error.
(Error al obtener datos: SAP DBTech JDBC: [4]: no se puede asignar suficiente memoria: error de falta de memoria devuelto desde CFL (HRESULT: 80131500)).
Cuando revisamos la operación de Fetch de la declaración costosa, está consumiendo más de 225 GB y debido a esto está fallando en el lado de Spotfire para la actualización de IL ya que hay un límite de memoria de 225 GB para que ID ejecute la consulta.
Por favor, avísenme si alguien ha enfrentado problemas de memoria con la operación de Fetch en SAP HANA 2.0.
Saludos,
Chandu
Por lo que veo, ya has reportado un Incidente de Soporte, el cual está siendo investigado por el Equipo de Desarrollo. Por favor, continúa en el incidente.
Ni siquiera encontré ninguna nota de apoyo o solución para esto.
Hay muy poca información aquí para determinar qué causa el OOM. Compartir los datos necesarios aquí probablemente sea mejor hacerlo en un incidente de soporte.
Sin embargo, unas observaciones:
- ejecutar una consulta en SAP HANA Studio generalmente conduce a una ejecución de consulta
limitada
Ya sea que se use la vista previa de datos; entonces se inyecta una cláusula LIMIT al SELECT y el conjunto de resultados se reduce en consecuencia, ya durante el procesamiento de la consulta. Alternativamente, SAP HANA Studio no recupera todos los registros de resultados, sino solo los primeros x (x=1000 de forma predeterminada).
Eso significa que la observación "funciona en HANA Studio pero no en Spotfire" probablemente no brinde información sobre la causa del problema.
- tu consulta de panel falla porque quiere asignar 225 GB de datos. Piensa en esto por un momento... Esto no puede ser la cantidad de datos que deseas devolver al panel. (es decir, la recuperación no es la causa del problema, sino simplemente la operación que provocó el error). Supongamos que el DV realmente no devuelve esa cantidad de datos al cliente, entonces significa que durante la ejecución del CV, se requiere esa cantidad de datos para el procesamiento intermedio.
Esto debería analizarse y corregirse revisando el modelo e intentando filtrar y agregar lo antes posible durante el procesamiento.
Cambiar el controlador JDBC o usar ODBC en su lugar no solucionará el modelo defectuoso.
contacto@primeinstitute.com
(+51) 1641 9379
(+57) 1489 6964
© 2024 Copyright. Todos los derechos reservados.
Desarrollado por Prime Institute