Avalados por :

Optimización de rendimiento en la ejecución de procedimientos almacenados en BPC 5.1 SP8 en SQL 2005

  • Creado 01/03/2024
  • Modificado 01/03/2024
  • 3 Vistas
0
Cargando...

Hola a todos,

Ejecutando BPC 5.1 SP8 en SQL 2005.

Servidor de base de datos y aplicación de un solo servidor en servidor de desarrollo Win2003 con 8 CPUs, 16 GB de RAM, sin actividad aparte de esta prueba.

Tengo un fragmento de lógica de script de BPC que llama a un procedimiento almacenado personalizado.

- Es un paquete de lógica estándar de BPC, solo la tarea de Ejecutar Fórmulas

- el paquete no hace nada más que llamar a la lógica.

- se llama como logic.LGX, no como LGF, por lo que no hay validación en tiempo de ejecución

- el archivo LGX contiene solo una línea:


*RUN_STORED_PROCEDURE=MyStoredProc('CATEGORY_SET%', 'Entity_SET%','ALL_DATASRC','ALL_TIME','ALL_SKU','NOSALESCHANNEL')

Está tardando más en ejecutarse de lo que me gustaría, y estoy tratando de entender por qué.

- Lo inicio desde eData -> Ejecutar Paquete

- aparece en la ventana de estado del paquete, unos segundos después

- lo primero que hace el procedimiento almacenado es registrar una marca de tiempo en un registro de transacciones

- a veces pasan 60 segundos desde que comienza el paquete hasta que comienza el procedimiento almacenado

No puedo entender por qué el servidor de aplicaciones tardaría 60 segundos antes de comenzar. ¿Alguna idea?

Gracias,

Tim

Pedro Pascal
Se unió el 07/03/2018
Pinterest
Telegram
Linkedin
Whatsapp

4 Respuestas

0
Cargando...

Información adicional: He configurado algunos otros paquetes DTS para ejecutar otros procedimientos almacenados directamente, sin llamarlos desde el archivo LGX, como parte de un conjunto más complejo de tareas de gestión de datos. No hay ninguna tarea de lógica SQL de BPC ("Ejecutar fórmulas") en estos.

Cuando ejecuto uno, comienza inmediatamente, registra los tiempos de inicio y fin en tblDTSLog (diferencia de 5 segundos) y ejecuta los 3 procedimientos almacenados (llamados desde 3 tareas en el paquete) dentro de esos 5 segundos.

Así que creo que el problema está definitivamente en la forma en que K2RunLogic está manejando la llamada al procedimiento almacenado.

Mi objetivo final es integrar este paquete problemático en un paquete personalizado (similar al de 5 segundos), no por esta razón de rendimiento, sino porque es la única forma que he encontrado para pasar el ID del usuario, lo que me permite realizar algunas comprobaciones de autorización.

Pero resulta que también puedo obtener un impulso de rendimiento con ese enfoque. Aun así, me gustaría tener la opción de usar RUN_STORED_PROCEDURE.

Respondido el 15/04/2024
LUCIANO RIOJA GHIOTTO
Se unió el 13/07/2019
0
Cargando...

Sin embargo, cuando llamo a mi procedimiento almacenado desde SQL Management Studio, por supuesto, comienza de inmediato. Configuraré otro SPRunCalcAccount en la aplicación de ventas para calcular algo trivial, como prueba. Gracias por tu ayuda, Sorin.

Respondido el 15/04/2024
LUCIANO RIOJA GHIOTTO
Se unió el 13/07/2019
0
Cargando...

Aquí tienes un registro de depuración (nuevamente recortado) para otra pieza de lógica, que incluye 5 pasos

- paso 1 es un script SQL de BPC

- paso 2 es un script SQL de BPC

- paso 3 es SPRunCalcAccount

- paso 4 es un script SQL de BPC

- paso 5 es SPRunCalcAccount

Toda la rutina tarda solo 37 segundos, incluidas las 2 llamadas a stored procs.

Diferencias clave que puedo ver:

- Aplicación Consol, no Ventas

- SPRunCalcAccount, no el procedimiento almacenado personalizado MyStoredProc



****************************************************************************************************
Inicio hora --->6:23:11 PM  -  Fecha:3/6/2009  (código de compilación :254)
****************************************************************************************************

Usuario:AP\tklem
Conjunto de aplicaciones:BPTAsPac
Aplicación:CONSOL
Modo de lógica:1
Lógica por:
Ámbito por:
Archivo de datos:
Archivo de depuración:D:\BPC\Data\Webfolders\BPTAsPac\CONSOL\PrivatePublications\tklem\TempFiles\\DebugLogic_13_.Log
Archivo de lógica:D:\BPC\Data\WebFolders\BPTAsPac\CONSOL\\..\AdminApp\CONSOL\FinStmt.LGF
Selección:D:\BPC\Data\WebFolders\BPTAsPac\CONSOL\PrivatePublications\tklem\TempFiles\FROM_13_.TMP
Modo de ejecución:1
Tamaño de consulta:0
Delimitador:,
Tipo de consulta:0
Simulación:0
Diferencia de cálculo:0
Script de fórmula:
Máx miembros:
Modo de prueba:0
¿Es modelado:1

Número de llamadas de lógica:1
----------------------------------------------------------------------------------------------------
Llamada no. 1, lógica:D:\BPC\Data\WebFolders\BPTAsPac\CONSOL\\..\AdminApp\CONSOL\FinStmt.LGF
----------------------------------------------------------------------------------------------------

-------------------------
Construyendo subconsulta 1
-------------------------
<snip>

Tiempo para cargar propiedades:0.0 seg.
----------------------------------------------------------------------------------------------------
<snip>
----------------------------------------------------------------------------------------------------
Tiempo para cargar datos de fuente:0.3 seg.
Ningún registro para procesar

-------------------------
Construyendo subconsulta 
        
Respondido el 15/04/2024
LUCIANO RIOJA GHIOTTO
Se unió el 13/07/2019
0
Cargando...

Ok. La siguiente pregunta es:

¿Tienes este problema al llamar a cualquier procedimiento almacenado o especialmente a uno en particular?

Si es para cualquier procedimiento almacenado, entonces el problema está en K2logic cuando accede al SP.

Si es para un SP específico, debes revisar ese SP.

Saludos

Sorin

Respondido el 15/04/2024
LUCIANO RIOJA GHIOTTO
Se unió el 13/07/2019

contacto@primeinstitute.com

(+51) 1641 9379
(+57) 1489 6964

© 2024 Copyright. Todos los derechos reservados.

Desarrollado por Prime Institute

¡Hola! Soy Diana, asesora académica de Prime Institute, indícame en que curso estas interesado, saludos!
Hola ¿Puedo ayudarte?