Avalados por :

Otimização de desempenho na execução de procedimentos armazenados no BPC 5.1 SP8 no SQL 2005.

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

Olá a todos,

Executando BPC 5.1 SP8 no SQL 2005.

Servidor de banco de dados e aplicação de um único servidor no servidor de desenvolvimento Win2003 com 8 CPUs, 16 GB de RAM, sem atividade além deste teste.

Tenho um trecho de lógica de script BPC que chama um procedimento armazenado personalizado.

- É um pacote de lógica padrão do BPC, apenas a tarefa de Executar Fórmulas

- o pacote não faz mais nada além de chamar a lógica.

- é chamado como logic.LGX, não como LGF, então não há validação em tempo de execução

- o arquivo LGX contém apenas uma linha:


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

Está demorando mais para ser executado do que eu gostaria, e estou tentando entender por quê.

- Eu inicio a partir de eData -> Executar Pacote

- aparece na janela de status do pacote, alguns segundos depois

- a primeira coisa que o procedimento armazenado faz é registrar um carimbo de tempo em um registro de transações

- às vezes passam 60 segundos desde o início do pacote até o início do procedimento armazenado

Não consigo entender por que o servidor de aplicativos levaria 60 segundos antes de começar. Alguma ideia?

Obrigado,

Tim

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

4 Respuestas

0
Cargando...

Informações adicionais: Configurei alguns outros pacotes DTS para executar outros procedimentos armazenados diretamente, sem chamá-los do arquivo LGX, como parte de um conjunto mais complexo de tarefas de gestão de dados. Não há nenhuma tarefa de lógica SQL do BPC ("Executar fórmulas") nessas.

Quando eu executo um, ele começa imediatamente, registra os tempos de início e fim no tblDTSLog (diferença de 5 segundos) e executa os 3 procedimentos armazenados (chamados de 3 tarefas no pacote) dentro desses 5 segundos.

Então, acredito que o problema está definitivamente na forma como o K2RunLogic está lidando com a chamada ao procedimento armazenado.

Meu objetivo final é integrar este pacote problemático em um pacote personalizado (similar ao de 5 segundos), não por essa razão de desempenho, mas porque é a única maneira que encontrei de passar o ID do usuário, o que me permite fazer algumas verificações de autorização.

Mas acontece que também posso obter um impulso de desempenho com essa abordagem. Ainda assim, gostaria de ter a opção de usar RUN_STORED_PROCEDURE.

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

No entanto, quando chamo meu procedimento armazenado do SQL Management Studio, é claro, começa imediatamente. Configure outro SPRunCalcAccount na aplicação de vendas para calcular algo trivial, como teste. Obrigado pela ajuda, Sorin.

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

Aqui tens um registo de depurao (novamente recortado) para outra pea de lgica, que inclui 5 passos

- passo 1 um script SQL de BPC

- passo 2 um script SQL de BPC

- passo 3 SPRunCalcAccount

- passo 4 um script SQL de BPC

- passo 5 SPRunCalcAccount

Toda a rotina demora apenas 37 segundos, incluindo as 2 chamadas a stored procs.

Diferenas chave que posso ver:

- Aplicao Consol, no Vendas

- SPRunCalcAccount, no o procedimento armazenado personalizado MyStoredProc



****************************************************************************************************
Incio hora --->6:23:11 PM  -  Data:3/6/2009  (cdigo de compilao :254)
****************************************************************************************************

Usurio:AP\tklem
Conjunto de aplicaes:BPTAsPac
Aplicao:CONSOL
Modo de lgica:1
Lgica por:
mbito por:
Arquivo de dados:
Arquivo de depurao:D:\BPC\Data\Webfolders\BPTAsPac\CONSOL\PrivatePublications\tklem\TempFiles\\DebugLogic_13_.Log
Arquivo de lgica:D:\BPC\Data\WebFolders\BPTAsPac\CONSOL\\..\AdminApp\CONSOL\FinStmt.LGF
Seleo:D:\BPC\Data\WebFolders\BPTAsPac\CONSOL\PrivatePublications\tklem\TempFiles\FROM_13_.TMP
Modo de execuo:1
Tamanho de consulta:0
Delimitador:,
Tipo de consulta:0
Simulao:0
Diferena de clculo:0
Script de frmula:
Mx membros:
Modo de teste:0
Modelado:1

Nmero de chamadas de lgica:1
----------------------------------------------------------------------------------------------------
Chamada no. 1, lgica:D:\BPC\Data\WebFolders\BPTAsPac\CONSOL\\..\AdminApp\CONSOL\FinStmt.LGF
----------------------------------------------------------------------------------------------------

-------------------------
Construindo subconsulta 1
-------------------------
<snip>

Tempo para carregar propriedades:0.0 seg.
----------------------------------------------------------------------------------------------------
<snip>
----------------------------------------------------------------------------------------------------
Tempo para carregar dados de fonte:0.3 seg.
Nenhum registro para processar

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

Ok. A próxima pergunta é:

Você está tendo esse problema ao chamar qualquer procedimento armazenado ou especificamente um em particular?

Se for para qualquer procedimento armazenado, então o problema está no K2logic ao acessar o SP.

Se for para um SP específico, você deve revisar esse SP.

Saudações

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?