Linha Microsiga Protheus

Árvore de páginas

Versões comparadas

Versão antiga 30

changes.mady.by.user Karen Regina De Barros Feliz

Gravado em

comparado com

Nova versão 31

changes.mady.by.user Karen Regina De Barros Feliz

Gravado em

Chave

  • Esta linha foi adicionada.
  • Esta linha foi removida.
  • A formatação mudou.

O objetivo deste documento é orientar o autoatendimento para sanar problemas de baixa performance.

Bem como, conduzir no levantamento de dados para análise técnica no intuito de rastrear as causas e possíveis formas de tratar.


01. LENTIDÃO GENERALIZADA NO SISTEMA

  1. Avalie se a baixa performance é generalizada ao processar grandes volumes de dados, ou se a lentidão ocorre isoladamente em determinada rotina / determinado processamento. Isso irá indicar se a origem do problema está no código fonte de uma rotina, ou, se está em artefatos estruturais e de Tecnologia, norteando a análise.
  2. Caso a lentidão não seja isolada em uma rotina / um processamento específico, então, é primordial analisar criteriosamente os fatores abordados no material: Framework - Lentidão no Protheus
  3. Você poderá solicitar apoio de sua TI para análise de Infra local, e apoio de seu administrador do sistema para análise da estrutura do Protheus.
  4. Você poderá solicitar Suporte Técnico da área de Framework Protheus, caso necessário, e acionar a área de Cloud se seu ambiente estiver armazenado no DataCenter da TOTVS.


Column
Dica
titleDica

Se o problema de performance for causado devido à limitações de estrutura/banco de dados, neste caso, não é caracterizado uma falha no Produto (de forma que caiba direcionar o caso para correção). Para apoio no diagnóstico e manutenções de seu ambiente e base, caso não possua equipe de DBA / TI Infra, contate a TIS nossa área especializada TOTVS Infra-Services. Conheça também nossas soluções de Delivery Center.

Column
width1


02. LENTIDÃO ISOLADA EM UMA ROTINA | PROCESSAMENTO ESPECÍFICO

Alguns fatores preciam ser previamente validados, uma vez que, frequentemente são a causa da lentidão. Execute cada um dos passos a seguir (preferencialmente em um ambiente/base de testes no qual seja simulada a lentidão - copiados de ambiente produção).

2.1 Realize as principais atualizações do sistema e confira se o problema é apresentado, mesmo num ambiente todo atualizado, para descartar que seja essa a causa do problema.

DBccess | Appserver e Smartclient (Lobo Guará ou Harpia)
LIB (Logo Guará ou Harpia) | Central de Atualizações
Acumulado expedição contínua módulo SIGAEST | Acumulado expedição contínua demais módulos

2.2 Desative as customizações do ambiente e confira se o problema é apresentado, mesmo num ambiente todo padrão, para descartar que seja essa a causa do problema. Desativar impreterivelmente pelos 3 métodos: Como desativar customizações no Protheus

2.3 Verifique as personalizações de seus dicionários e confira se o problema é apresentado, mesmo com dicionários de dados (SXs) nativos, ou seja, realize um teste com os dicionários (completo e diferencial) oficiais disponibilizados no Portal de Downloads sem quaisquer personalizações. Esse procedimento visa identificar se a lentidão ocorre isoladamente em decorrência de alguma particularidade personalizada em seus dicionários, de modo a refinar o foco da análise.

    • Personalizações elaboradas sem o devido critério.
      Ex: Uso da função GETSXENUM no Inicializador padrão do B1_COD para atribuir numeração automática.
    • Alterações no nível de campos, marcação de "usado" e posicionamento de campos travados no CFG.
    • Alteração no compartilhamento de tabelas e demais mudanças estruturais não apropriadas.


2.4 Critérios que devem ser avaliados pontualmente de acordo com o cenário problemático:

Deck of Cards
effectDuration0.5
idFuncionalidadesEST
effectTypeslide
Card
defaulttrue
effectDuration0.5
label| PROCEDURE ATIVA
effectTypeslide

A lentidão ocorre somente com Stored procedures ativas no Banco?

Stored Procedures são comandos via código que tem a finalidade de otimizar a busca no banco de dados de determinadas informações. A TOTVS sugere algumas stored procedures para agilizar a interação de determinadas rotinas com o Banco de Dados. O uso é facultativo e requer a gestão de um DBA para monitoramento, adequação e manutenções que se façam necessárias, tanto nos códigos, quanto no Banco para o devido funcionamento.

Se a lentidão ocorrer apenas com a utilização de procedures no Banco, então é fundamenta solicitar inicialmente a seu DBA que efetue um monitoramento do processamento da rotina via Banco para diagnóstico.


Expandir
titleProcedimentos que necessariamente devem ser executados pelo DBA




  • Fragmentação de Tabelas e index do banco de dados
    Verificar se há tabelas que estão desfragmentadas. A fragmentação das tabelas diminui a performance do banco de dados e da aplicação.     É necessário efetuar a desfragmentação das tabelas e tablespaces do banco de dados da aplicação, com o objetivo de melhorar as operações de DML e DQL no banco e aumentar a performance das rotinas do Protheus.Frequentemente a fragmentação de índices também ocasiona perda considerável de performance. Com o grande número de inserções, alterações e exclusões que ocorrem nas tabelas, os índices se fragmentam recorrentemente, e necessitando de manutenção para que não ocasione lentidão na manipulação dos dados desses índices. É necessário analisar se há índices pertencentes às tabelas da aplicação que estão fragmentados, e ocasionalmente realizar o Rebuild dos índices das tabelas da aplicação.


  • Estatísticas do Banco


    • SQL Server:
      Verifique se as estatísticas das tabelas do banco de dados do Protheus estão atualizadas, pois com as estatísticas desatualizadas causa impacto na performance da aplicação. Caso esteja desatualizado, colete as estatísticas do schema e do dicionário de dados do banco de dados.
      Dois parâmetros existentes em bases SQL Server podem trazer efeitos de melhor experiência no Protheus, e devem ser estudados pelo DBA:
      Auto Update Statistics – configurada como True, as estatísticas de índice são automaticamente atualizadas.
      Auto Create Statistics – configurada como True, as estatísticas de índice são automaticamente criadas, sempre que você criar um índice, na execução de cada instrução o SQL Server cria um conjunto de estatísticas sobre os dados contidos dentro do índice.

      O otimizador de consulta utiliza essas estatísticas para determinar se deve ou não utilizar o índice para ajudar a processar a consulta, no caso do Protheus, sabendo onde está alocado o dado o retorno será mais rápido.
      É necessário efetuar a manutenção da base de dados, realizando a reindexação e ou reconstrução de índices e atualização de estatísticas além de monitorar o espaço para crescimentos dos arquivos de dados e arquivos de log do banco de dados. Verifique também a consistência física e lógica da base de dados.
  •  
    • Oracle:
      O DataBase Oracle precisa de uma boa estatística para tomar as melhores decisões que puder quanto ao caminho de acesso mais apropriado. Sem nenhuma estatística, o DataBase deve fazer suposições sobre quais são os melhores caminhos de acesso ao dado. Em muitos casos, conduz oescolher caminhos menos performáticos. As estatísticas que são reunidas incluem estatísticas sobre tabelas, número de linhas, número de blocos, estatísticas sobre colunas, número de valores distintos, número de NULLs e distribuição de dados, estatísticas sobre índex, número de blocos, tamanho do index, fator cluster, e estatísticas sobre desempenho de Sistema.      Há dois métodos utilizados para a coleta de estatísticas: o comando analyze e o pacote fornecido dbms_stats. O Método dbms_stats é o mais utilizado para calcular estatísticas para o database e, em versões futuras, será a única maneira de calcular estatísticas. No método dbms_stats recomendamos o uso através dos scripts abaixo.

      Método gather_schema_stats: O gather_schema_stats calcula as estatísticas para todos os objetos em um dado esquema. As estatísticas podem ser colocadas no dicionário de dados ou na tabela de estatísticas de um usuário. Recomendamos o uso do script abaixo.
      exec sys.dbms_stats.gather_dictionary_stats (comp_id => null, estimate_percent => null, method_opt => 'FOR ALL COLUMNS size AUTO', degree => 2, cascade => TRUE,no_invalidate => true);
      execsys.dbms_stats.gather_schema_stats('PROTHEUS',CASCADE=>TRUE,METHOD_OPT=>'FOR ALL INDEXED COLUMNS');
      Recomendamos o uso da coleta de estatística do dicionário do database e do owner em que se encontram os dados do Protheus.



Column
width4
Aviso
titleAtenção

Caso o DBA indique alguma necessidade de análise pontual da aplicação Protheus - Estoque e Custos / ACD, é necessário acionar o Suporte Técnico por meio de um novo ticket, encaminhando o relatório de análises e manutenções realizadas, índices e querys monitorados e respectivo diagnóstico; bem como, o envio dos insumos solicitados na seção '03 - LEVANTAMENTO DE INSUMOS PARA ANÁLISE DO SUPORTE TÉCNICO'. Neste caso, a análise é realizada na modalidade de Consultoria.

Column
width1


Column
width4
Nota
titleImportante

Os procedimentos de análise, diagnóstico e manutenções no banco são de responsabilidade do DBA da empresa. Caso não possua um DBA em seu time de TI interno, a TOTVS disponibiliza o serviço através da área TIS - TOTVS Infra Services. Solicite um orçamento por meio deste contato.
Caso seu banco de dados/ambiente esteja armazenado no Cloud Data Center da TOTVS, acione a área por meio de um novo ticket solicitando esse serviço.

Card
defaulttrue
effectDuration0.5
label| CUSTO MÉDIO
effectTypeslide
  • Testar se a performance é otimizada com a configuração de parâmetros: MV_M330THR=1 e MV_M330JCM= em branco
  • Valide a necessidade de usar o parametro MV_A330GRV caso esteja ativo. Este parâmetro é recomendado para clientes que possuem uma quantidade de registros na tabela SB2 superior a 10 mil registros, pois ele evita o processamento desnecessário de produtos/armazém obsoletos que não tem necessidade de recálculo. Para uma melhor performance o parâmetro deve estar configurado com o conteúdo igual a .F. (False).
    Caso utilize os pacotes de stored procedures para execução da rotina é recomendada a reinstalação das SP's após a alteração deste parâmetro, sem esta ação o objetivo de melhora no desempenho não será atingido.
  • Utilizar as procedures referente a rotina e certificar-se de que estejam atualizadas (Stored Procedures Estoque)
  • O parametro MV_MOEDACM considera o cálculo no padrão para 5 moedas de forma simultânea. Caso não tenha necessidade de calcular moedas estrangeiras, considerar o conteúdo do parametro em branco e avaliar se há otimização no desempenho.
  • Verificar os pontos detalhados no material: MATA330 - Como melhorar a performance da rotina de Recálculo do Custo Médio
Card
effectDuration0.5
label| CONTABILIZAÇÃO do custo
effectTypeslide

Em construção.

Card
effectDuration0.5
label| REFAZ SALDOS
effectTypeslide

Em construção.

Card
effectDuration0.5
label| REFAZ PODER DE TERCEIROS
effectTypeslide

Em construção.

Card
effectDuration0.5
label| REFAZ CUSTO DE ENTRADA |
effectTypeslide

Em construção.

03. LEVANTAMENTO DE INSUMOS PARA ANÁLISE DO SUPORTE TÉCNICO

Providencie criteriosamente os insumos solicitados abaixo na Aba 1ª ETAPA para enviar pra análise do Suporte Técnico. Providencie os artefatos e envie já na abertura do ticket.

Dica
titleImportante

Se seu ambiente estiver armazenado no Cloud da TOTVS, e você não tiver acesso para obter algum dos insumos abaixo solicitados, através da plataforma TCloud, então, acione primeiramente o Suporte Cloud solicitando a geração dos insumos. Com eles disponíveis, então solicite o Suporte Técnico da área enviando os dados levantados.

Deck of Cards
id001
tabLocationleft
Card
label1ª ETAPA SUPORTE TÉCNICO

➡️ FORNECER AS SEGUINTES INFORMAÇÕES:

1. A lentidão ocorre isoladamente em qual processamento? (Exemplo: ocorre isoladamente no processamento do custo médio)
2. Qual o atual tempo de processamento, para qual quantidade de registros? E qual a sua expectativa de tempo considerável para esse mesmo volume de dados?
3. Quando a lentidão começou nesse processamento? Sempre existiu ou foi a partir de 'alguma mudança em sua estrutura do sistema' / 'alguma atualização específica aplicada'?


➡️ PROVIDENCIAR OS SEGUINTES INSUMOS:
(Obs: Caso seu ambiente possua Load Balance Balanceamento de carga certifique-se de isolar um servidor para efetuar os testes de performance)

1. Gerar o LogProfiler para coleta do processamento de execução da rotina, exatamente conforme o boletim: SIGAEST LogProfiler
2. Gerar o Log DBTrace para coleta do processamento de dados, exatamente conforme o boletim: OINF0001 - DBTrace
3. Extrair o Inspetor de objetos "Exportar dados", extamente conforme a instrução: Exportar Dados - Linha Protheus
4. Capturar e enviar a tela de geração MallocIO para investigação de alocação de memória (como gerar)-(Caso ambiente seja CLOUD não há necessidade de efetuar esse procedimento).

(Obs: Caso seu ambiente possua Load Balance Balanceamento de carga certifique-se de isolar um servidor para efetuar os testes de performance)


Expandir
titleSE a lentidão for no processamento do CUSTO MÉDIO
  • Enviar a tabela CV8 completa em formato .dtc filtrada com CV8_PROC = Nome da rotina (Obs: efetuar pela rotins legado, MATA330)
  • Informar se utiliza Stored Procedures ativas, e qual o comportamento obtido sem procedures.
Expandir
titleSE a lentidão for na CONTABILIZAÇÃO do custo médio
  • Enviar o Trace/Log para análise no desempenho da integração contábil: MV_CONOUTR



Card
label2ª ETAPA CONSULTORIA

Análises de performance podem ser complexas, pois envolvem uma diversidade grande de fatores e variáveis, distribuídas entre:
Banco de dados | Configurações e características estruturais do ambiente | Produto em si (códigos padrões do sistema)

Deste modo, caso o analista de Suporte Técnico realize a primeira etapa de análise e os insumos não forneçam indícios concretos da causa do problema, estão será necessário seguir os passos listados a seguir:


  1. Verifique o boletim FRAME - Lentidão no Protheus 12 e siga criteriosamente cada uma das recomendações para validação do ambiente Protheus
  2. Certifique-se de estar utilizando um Banco de dados homologado para o Protheus
  3. Efetue a devida configuração e atualização dos arquivos Dbapii.dll nas pastas DBAcess e Appserver
  4. Utilize a chave DBPulse ativa, caso o ambiente esteja em um servidor Cloud, e avalie se há resultado sobre o tempo de processamento
  5. Caso o ambiente esteja em seu servidor On-Premise, certifique-se de possuir a estrutura mínima recomendada: Instalação de Protheus em On Premise
  6. Verifique como está configurada a conexão do ambiente no ODBC. Para melhor performance recomenda-se que seja criada com o driver SQL Server Native Client
  7. Valide o comportamento obtido em ambiente teste com os dicionários de dados (SXs) nativos, inclusive compartilhamento de tabelas. Ou seja, utilizando os dicionários (completo e diferencial) oficiais disponibilizados no Portal de Downloads sem quaisquer personalizações. Esse procedimento é essencial e visa identificar se a lentidão ocorre isoladamente em decorrência de alguma particularidade personalizada em seus dicionários, de modo a refinar o foco da análise.
  8. Identifique se a queda no desempenho ocorre especificamente em determinado período do dia. Caso sim, verifique se nesse horário está planejada a execução de algum processamento pesado, como por exemplo Job’s do TSS, Contabilização Off-Line, Reprocessamentos e etc.
  9. Solicite o apoio de um DBA* para acompanhar a execução da rotina e verificar os possíveis pontos de manutenção em seu data-base para otimizar o processamento, caso sua base de dados esteja em um banco de dados e não em CTREE.
  10. Solicite o apoio de um DBA* para validar a integridade de seus registros no banco de dados. Dados inconsistentes gravados na base frequentemente produzem efeitos inesperados no processamento (Ex: dados incorretos em tabelas consultadas para o processamento em questão, como SB2, SB9, SB6, SD1, SD2 e SD3 etc. Campos obrigatórios gravados sem conteúdo, como código, filial, armazém, etc.)
  11. Solicite o apoio de sua TI Infra* para diagnostifar sua estrutura de Hardware / Rede e latência (conheça a funcionalidade U_NETTEST).

* Se o problema de performance for causado devido à limitações de estrutura/banco de dados, neste caso, não é caracterizado uma falha no Produto (de forma que caiba direcionar o caso para correção). Para apoio na análise e diagnóstico de seu ambiente e base, caso não possua equipe de DBA / TI Infra, contate a TIS nossa área especializada TOTVS Infra-Services.


ESSA SEGUNDA ETAPA DE ANÁLISE PODE SER REALIZADA PELO SUPORTE TÉCNICO TOTVS ATRAVÉS DA MODALIDADE DE CONSULTORIA DO SUPORTE

Para isto, é necessário que envie ao Suporte o seu parecer acerca de cada item listado nesta etapa, e envie também os seguintes logs para análise:


Cada questão e log solicitados foram elaborados para prover uma análise assertiva e criteriosa em ocorrências de performance. Por isso, havendo dúvidas, solicite apoio à seu time de TI para que todas as questões sejam devidamente respondidas. Elas são essenciais para o atendimento.