Árvore de páginas

Versões comparadas

Chave

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

...

Deck of Cards
effectDuration0.5
idFuncionalidadesEST
effectTypeslide
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.


5. A lentidão ocorre somente com as procedures de processamento ATIVAS?

Deck of Cards
effectDuration0.5
idFuncionalidadesEST
effectTypeslide

Se caso a lentidão ocorrer apenas com a utilização das procedures, devera inicialmente solicitar ao seu analista DBA, que efetue um acompanhamento do processamento da rotina, com a coleta do Profiler no banco de dados, afim de identificar se existe a possibilidade de criação de indices adicionais durante a coleta do profiler bem como solicitar que o mesmo valide as questão do ITEM 3 do boletim seguinte:

É extremamente importante que seja avaliado os pontos pelo analista DBA, e encaminhado os dados de analise dos indices aplicaveis, e qual a manutenção realizada.

Framework - Linha Protheus - Lentidão no Protheus 12

3. Manutenção
3.1. Fragmentação de Tabelas, SQL Server
Verifique se há tabelas e index do banco de dados que estão desfragmentadas. A fragmentação das tabelas diminui a performance do banco de dados e da aplicação. Efetue 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 de dados e aumentar a performance das rotinas do Protheus.

Um dos grandes problemas que temos com relação a performance é devido a fragmentação de nossos índices. Com o grande número de inserções, alterações e exclusões que ocorrem em nossas tabelas, os índices se fragmentam cada vez mais, ocasionando uma lentidão na manipulação dos dados desses índices.

Verifique se há índices pertencentes às tabelas da aplicação que estão fragmentados, pois quando estes índices estão fragmentados, diminui a performance da aplicação e do banco de dados. Neste caso realize o Rebuild dos índices das tabelas da aplicação.

3.2.  Estatísticas do 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, com o objetivo de melhorar a performance.

Dois parâmetros existentes em bases SQL Server podem trazer efeitos de melhor experiência do Protheus:

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 ele 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.

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. Estes procedimentos são de responsabilidade do DBA da empresa, caso não possua DBA a equipe de consultoria da TOTVS poderá ser acionada para esta avaliação.

3.3. Coleta de Estatística do 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 o DataBase a escolher 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, porém em versões futuras, o pacote dbms_stats será a única maneira de calcular estatísticas. Vale ressaltar que o método dbms_stats é o que recomendamos o seu 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.

Recomendamos o uso da coleta de estatística do dicionário do database e do owner que se encontra os dados do Protheus.

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');


Links Uteis: 

Como gerar o Trace para monitor a performance de Stored Procedures SQL Server

Como gerar o Trace para monitor a performance de Stored Procedures Oracle (TKPROF)



...

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

...

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'?
4. A lentidão ocorre somente com as procedures de processamento ATIVAS?

Se caso a lentidão ocorrer apenas com a utilização das procedures, devera inicialmente solicitar ao seu analista DBA, que efetue um acompanhamento do processamento da rotina, com a coleta do Profiler no banco de dados, afim de identificar se existe a possibilidade de criação de indices adicionais durante a coleta do profiler bem como solicitar que o mesmo valide as questão do ITEM 3 do boletim seguinte:

É extremamente importante que seja avaliado os pontos pelo analista DBA, e encaminhado os dados de analise dos indices aplicaveis, e qual a manutenção realizada.

Framework - Linha Protheus - Lentidão no Protheus 12



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).


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.

...