Linkedin

Total de visualizações de página

domingo, 11 de junho de 2023

Os principais comandos do editor de texto Vi

Comando Descrição                                                  

 `i`                Entra no modo de inserção (para começar a digitar o texto) 

 `Esc`           Sai do modo de inserção e volta para o modo de comando    

 `h`               Move o cursor para a esquerda                             

 `j`                Move o cursor para baixo                                  

 `k`               Move o cursor para cima                                  

 `l`                Move o cursor para a direita                              

 `0` (zero)     Move o cursor para o início da linha                      

 `$`               Move o cursor para o final da linha                       

 `gg`             Vai para o início do arquivo                              

 `G`              Vai para o final do arquivo                               

 `Ctrl + f`     Avança uma página                                         

 `Ctrl + b`     Retrocede uma página                                      

 `x`               Exclui o caractere sob o cursor                           

 `dd`             Apaga a linha inteira                                     

 `yy`            Copia a linha atual                                       

 `p`              Cola o texto copiado após o cursor                        

 `u`              Desfaz a última alteração                                 

 `Ctrl + r`    Refaz a última alteração desfeita                         

 `/texto`       Procura pelo texto especificado                           

 `n`             Vai para a próxima ocorrência do texto encontrado         

 `N`            Vai para a ocorrência anterior do texto encontrado        

 `:w`           Salva o arquivo                                           

 `:q`            Sai do Vi                                                 

 `:q!`           Sai do Vi sem salvar alterações                           

 `:wq` ou `:x` Salva e sai do Vi                                         


Esses são apenas alguns dos comandos básicos do Vi. Existem muitos outros comandos e funcionalidades disponíveis. 

sexta-feira, 11 de fevereiro de 2022

Sistemas operacionais homologados Windows - TOTVS Protheus

 Fonte: https://tdn.totvs.com/display/tec/Application+Server+19.3.0.x+e+superiores+-+Sistemas+operacionais#produto-menu-link-content

sábado, 16 de outubro de 2021

Connection blocked. The DBAPI [20200910] used on the application server is out of date

Implementar validação no TOTVS | DBAccess para bloquear conexões que se originem de um TOTVS | Application Server que esteja utilizando uma DBAPI desatualizada.


A partir desse release serão comparadas as constantes de build da DBAPI e TOTVS | DBAccess, desconsiderando a data de compilação do binário.

Por exemplo: validar se a DBAPI e DBAccess estão com build 20210202.

Caso uma conexão seja bloqueada por se originar de uma DBAPI desatualizada, a seguinte mensagem será gravada no console das aplicações:

TOTVS | DBAccess:

[tSockDBServer][ERROR] Connection blocked. The DBAPI [20200910] used on the application server is out of date.

TOTVS | Application Server LG ou superior:

Error - TOPCONN - No connection: -97 - DBAPI_OUTDATED : Connection blocked. The DBAPI [20200910] used on the application server is out of date.

TOTVS | Application Server NG:

Warning - TOPCONN - No connection: -97 - Undefined tTopError

Fonte: 

https://tdn.engpro.totvs.com.br/pages/viewpage.action?pageId=593059466

terça-feira, 5 de outubro de 2021

Como denominar variavel com a Notação Húngara

 

Pessoal, a Notação Húngara foi proposta por Charles Simonyi, e tem como objetivo facilitar o reconhecimento de qualquer tipo de variável em um código fonte.

A origem do nome da notação foi caracterizada a partir de uma brincadeira dos primeiros que trabalharam com a linguagem. Eles teciam o seguinte comentário:

“O nome das variáveis fica tão estranho que até parece Húngaro”

Existem algumas convenções para se denominar as variáveis. Vamos a elas:

Implementar nome mnemônico com significado – tem como objetivo facilitar a lembrança do significado da variável pelo programador.

Utilize nomes curtos e simples – facilita a programação e evita erros de compilação.

A notação Húngara é simples e intuitiva. Veja só:

  • Defina a variável de com um nome curto, simples, intuitivo.
  • A primeira letra do nome é maiúscula e restante das letras é minúscula. Assim como o meu e o seu nome. Por exemplo, Pedro.
  • Insira o tipo da variável em letra minúscula, respeitando a tabela abaixo, a frente do nome variável.
NomeDescrição
sString
szAponta o primeiro caracter da terminação zero da string
stPonteiro da string, o primeiro byte é contado dos caracteres
hhandle (título)
msgMessage
fnfunction (usada com pointer)
cchar (8 bits)
byunsigned char (byte or uchar – 8 bits)
nInt
bBoolean (verdadeiro ou falso)
fFlag (boolean, logical)
uinteger
wWord
chChar, com texto ASCII
llong int (32 bits)
dwunsigned long int (dword – 32 bits)

Veja alguns exemplos.

bVerdadeboolean
sNomestring
uValorinteiro
msgAvisomessage
fonte: https://engenhariasoftware.wordpress.com/2020/05/11/notacao-hungara-para-denominar-uma-variavel/

sexta-feira, 17 de setembro de 2021

DVARLOJ4-7935 DT Venda Assistida valor total incorreto ao deletar itens no grid

1. DADOS GERAIS

Produto:

TOTVS Varejo Lojas

Linha de Produto:

Linha Protheus

Segmento:

Varejo

Módulo:Controle de Lojas (SIGALOJA)
Função:Venda Assistida
Issue  :DVARLOJ4-7935
Fontes do Pacote:CFGX019.PRW 19/06/2019 08:32:42
ENGXFUN.PRW 06/07/2018 17:14:58
FISLOAD.PRW 26/02/2019 11:20:47
FW_RESOURCE_PKMK.PNG 17/05/2019 16:22:08
LOJA701.PRW 03/06/2020 09:19:09


02. 
SITUAÇÃO/REQUISITO

Na rotina Venda Assistida (SIGALOJA), ao inserir itens na grid e deletar um de cada vez , o Sistema não atualizava o valor Total, ficando com o valor incorreto.

03. SOLUÇÃO

Efetuado ajuste na rotina Venda Assistida, permitindo que ao deletar itens da venda, o valor Total  seja apresentado corretamente.

04. DEMAIS INFORMAÇÕES

A inconsistência só ocorria nas versões de Build 19.3.0.1 e 19.3.0.2.


Fonte::

https://tdn.engpro.totvs.com.br/display/public/PROT/DVARLOJ4-7935+DT+Venda+Assistida+valor+total+incorreto+ao+deletar+itens+no+grid



quinta-feira, 3 de dezembro de 2020

SIGALOJA 0290 Quais são os logs auxiliares Protheus Varejo?

 Logs importantes que ajudam no diagnostico de diferentes tipo de problemas.



Produto:

SIGALOJA , Front Loja e TOTVS PDV

Versões:

11 e 12

  1. Trace nas rotinas dos módulos de Varejo

Quando utilizar: Identificar ocorrências relacionadas a Venda Assistida, TOTVS PDV, integração Protheus com plataforma Ciashop entre outros.
Para habilitar este recurso, é necessário configurar a seção abaixo no arquivo AppServer.ini:

[LOGLOJA]
Enable=1
Onde: Enable=0 (default) o log está desabilitado e Enable=1 o log está habilitado.

Resultado:
Será gerado um arquivo de log por dia na pasta Protheus_Data\Autocom\Logs.
Neste arquivo são geradas informações como:
1. Versão da build utilizada;
2. Versão e release do sistema;
3. Uma lista com a relação dos principais fontes do módulo varejo especificados por data e hora de compilação presentes no repositório;
4. Mensagens informativas de processamento das rotinas utilizadas na análise da ocorrência.

2. Trace de erro na comunicação entre hosts (TOTVS PDV)


Quando utilizar: Identificar mensagens quando ocorre algum erro na comunicação entre os hosts Retaguarda, Central de PDVs (se houver) e TOTVS PDV. Tem o conceito similar ao error.log.
Não é necessária nenhuma configuração para habilitar este recurso.

Resultado:
Na ocorrência de um erro, será criado o arquivo ERRORHOST.LOG na pasta \system.

3. Trace para a comunicação da SIGALOJA.DLL

Quando utilizar: Identificar ocorrências relacionadas a comunicação com o ECF (quando a comunicação é via SIGALOJA.DLL).
Para habilitar este recurso, é necessário que o arquivo SIGALOJA.INI, que deve estar na mesma pasta da SIGALOJA.DLL, tenha a seguinte seção configurada:

[LogDLL]
Log=1
Por favor, baixar a última versão do SIGALOJA.DLL disponível no portal do cliente.

Resultado:
Será criado o arquivo SIGALOJA.LOG na pasta \bin\smartclient.

4. Trace para o log do orçamento (gravação)

Quando utilizar: Identificar ocorrências relacionadas a gravação da Venda Assistida ou integração ERP do Front Loja ou TOTVS PDV.
Para habilitar este recurso, é necessário que o arquivo SIGALOJA.INI, que deve estar na mesma pasta da SIGALOJA.DLL, tenha a seguinte seção configurada:

[Logs TEF]
Habilita=01
Obs: Para os casos de integração ERP do Front Loja este log é gerado no TotvsConsole.log.

Resultado:
Para vendas efetuadas no SIGALOJA (Venda Assistida), será criado o arquivo texto com o número do orçamento na pasta <RootPath>\autocom\tef+<empresa>+<filial>\<número do orçamento>.txt
Enviar o arquivo correspondente ao orçamento relacionado à ocorrência.

5. Trace para comunicação do Protheus Remote com o Protheus Server

Quando utilizar: Identificar ocorrências relacionadas a queda do smartclient.
Este apresenta a comunicação entre o Server e o Remote.
Para habilitar este recurso, é necessário configurar o arquivo TotvsAppServer.ini, na seção:

[Config]
Locallog=1

Resultado:
A gravação do log será na pasta de arquivos temporários da máquina onde está sendo executado o SmartClient (totvssmartclient.log) com informações necessárias para diagnósticos de erros do Protheus Remote. Valor padrão = 0. Quando este arquivo atinge tamanho de 1MB é renomeado com o seguinte nome:
totvssmartclient_<ano>-<mes>-<dia>-<hora>-<minutos>-<segundos>.log

6. Trace das operações no Server

Quando utilizar: Identificar ocorrências relacionadas a queda do smartclient (LogMessages) e para coletar logs via Conout (Consolelog).
Para habilitar este recurso, é necessário configurar as chaves Consolelog e LogMessages na seção [General] do arquivo TotvsAppServer.ini:

[General]
Consolelog=1
LogMessages=1

Resultado:
Será criado o arquivo TotvsConsole.log na pasta \bin\appserver.

7. Trace do TopConnect

Quando utilizar: Identificar ocorrências relacionadas a gravação no banco de dados.
Os logs do Top Connect apresentam as operações realizadas no banco de dados (SGBD).

Resultado:
Arquivo Topconn.log
Arquivo Topconsole.log

8. Trace para a comunicação da BEMAFI32.DLL (ECF Bematech)

Quando utilizar: Identificar ocorrências relacionadas a comunicação com impressoras Bematech.
Para habilitar este recurso, é necessário que o arquivo BEMAFI32.INI, que deve estar na pasta \windows\system32, tenha a seguinte seção configurada:

[Sistema]
Log=1
Path=<path>
Baixar a última versão do BEMAFI32.DLL disponível no site da Bematech.

Resultado:
Será criado o arquivo BEMAFI32.LOG na pasta configurada na tag Path (ex: \windows\system32).

9. Trace para a comunicação da DARUMA.DLL (ECF Daruma)

Quando utilizar: Identificar ocorrências relacionadas a comunicação com impressoras Daruma.
Para habilitar este recurso, é necessário alterar o registro do Windows:
HKEY_LOCAL_MACHINE/SOFTWARE/DARUMA/ECF
Alterar a linha Log=1
Baixar a última versão do DARUMA.DLL disponível no site da Daruma.

Resultado:
Será criado o arquivo DARUMA.LOG na pasta indicada em Path.

10. Trace para comunicação da DARUMAFRAMEWORK.DLL (ECF Daruma)

Quando utilizar: Identificar ocorrências relacionadas a comunicação com impressoras Daruma (modelo de comunicação via DarumaFramework.DLL).
Para habilitar este recurso, procure pelo arquivo DarumaFramework.xml
Dentro deste arquivo procure na seção <ECF> a tag <Auditoria> e configure para 1.
Configure o caminho a gravar o log na tag <LocalArquivos>.

Resultado:
Será gerado o arquivo de log chamado Auditoria_ECF.txt.

11. Trace para o monitoramento de Pacotes
Quando utilizar: Identificar ocorrências relacionadas ao desempenho da rede.
Existe um recurso que podemos habilitar para monitorar o desempenho da rede, e com isso criar mais subsídios para avaliar os casos como “erro de sincronismo”.
1. Como este programa já está compilado no repositório padrão, basta chamar U_NETTEST
2. Inicie o processo de monitoramento
3. Este processo irá ficar rodando paralelamente na estação
4. Será gerado o arquivo de log na máquina do servidor, na pasta rootpath\nettest
12. Trace para o monitoramento de performance

Quando utilizar: Identificar ocorrências relacionadas a problemas de performance.
Para habilitar este recurso, é necessário configurar no TOTVSAppServer.ini na seção do Environment:
[Environment]
SourcePath=…
RootPath=…
StartPath=…
RpoDb=…
LogProfiler=1

Resultado:
Será criado o arquivo TotvsConsole.log na pasta \bin\appserver.
Este log indica a quantidade de chamadas de cada função, tempo total das chamadas/retornos e tempo da maior chamada, inclusive origem da chamada.
O recurso de LOGPROFILER é indicado para a análise de performance em rotinas e aplicações Advpl, em momento de desenvolvimento e/ou homologação, para avaliar a quantidade de instruções executadas e tempo de resposta destas instruções, para análise de pontos críticos, funções mais chamadas e pontos que podem ser melhorados em um processo. Também é indicado para as situações onde uma determinada rotina, que tinha um tempo médio de processo determinado, passou a apresentar, a partir de um determinado momento, um tempo maior de execução, e existe a necessidade de descobrir se o fator que desencadeou este comportamento está relacionado à algumas funções do código executado, que tiveram alteração de comportamento e tempo de resposta, ou até mesmo uma alteração de lógica ou implementação no código, onde uma ou mais funções tiveram funcionalidades agregadas que consequentemente acarretaram em um acréscimo no tempo de execução de cada chamada.
Como ler o log - LogProfiler - Profiler de ejecución de programas AdvPL - Interna

13. Trace para o monitoramento de customizações
Quando utilizar: Identificar ocorrências relacionadas a customizações.
Para habilitar este recurso, é necessário configurar no TOTVSAppServer.ini na seção do Environment:
[Environment]
SourcePath=…
RootPath=…
StartPath=…
RpoDb=…
IXBLOG=LOGRUN
Resultado:
Será criada automaticamente a pasta \Ixblog na pasta RootPath, com arquivos textos de log.
Mais informações em:
http://tdn.totvs.com/display/public/mp/Chave+IXBLOG;jsessionid=2C322BBA3BA544DDEFE1D01284E07898
14. Trace para a comunicação da AUTOCOM

Quando utilizar: Identificar ocorrências relacionadas a comunicação com impressoras e/ou TEF (quando a comunicação é via TOTVSAPI.DLL).
Log de comunicação com a Autocom (operações com ECF e/ou TEF).
Para habilitar este recurso, é necessário que exista o arquivo AUTOCOM.LOG na pasta do SmartClient. Inicialmente, este arquivo pode estar vazio.

Resultado:
Será atualizado o arquivo AUTOCOM.LOG na pasta \bin\smartclient.

15. Trace para a comunicação com TEF CLISITEF

Quando utilizar: Identificar ocorrências relacionadas a integração com TEF (SiTEF – Software Express).
Log de comunicação com o TEF CLISITEF.
Para habilitar este recurso, é necessário que o arquivo TOTVSAPI.INI, que deve estar na pasta do SmartClient, tenha a seguinte seção configurada:
[Log]
LogTEF=1
TamanhoLog=1000 //(1 MB)

Resultado:
Será criado o arquivo LjTEF+<estação>.log na pasta
<RootPath>\log\tef+<empresa>+ <filial>.

16. Trace para a comunicação com ECF via TOTVSAPI

Quando utilizar: Identificar ocorrências relacionadas a comunicação com impressoras (quando a comunicação é via TOTVSAPI.DLL).
Log de comunicação com ECF via TOTVSAPI .
Para habilitar este recurso, é necessário que o arquivo TOTVSAPI.INI, que deve estar na pasta do SmartClient, tenha a seguinte seção configurada:

[Log]
LogECF=1
TamanhoLog=1000 //(1 MB)

Resultado:
Será criado o arquivo LjECF+<estação>.log na pasta <RootPath>\log\ecf+<empresa>+<filial>.

17. Trace de chamadas de WebServices

Quando utilizar: Identificar ocorrências relacionadas a comunicação com a retaguarda via Web Services.
Log de chamadas de WebServices.
Para habilitar este recurso, é necessário que a seção do WebServices do arquivo TOTVSAppServer.ini, tenha a seguinte seção configurada:

[Job_WebServices]
TYPE=WEBEX ENVIRONMENT= ENVIRONMENT
INSTANCES=1,10 SIGAWEB=WS INSTANCENAME=WebServices ONSTART=__WSSTART ONCONNECT=__WSCONNECT PREPAREIN=01,01
TRACE=1

Resultado:
Será criado o arquivo wsstrace.log na pasta do dicionário de dados - SXs (system).

18. Trace para monitoramento de memória consumida

Quando utilizar: Identificar ocorrências relacionadas a consumo excessivo de memória.
Esta chave habilita uma coluna no TOTVS | Monitor, onde será informada a quantidade de memória utilizada para cada processo apresentado no monitoramento.
Para habilitar este recurso, é necessário configurar no TOTVSAppServer.ini na seção General:

[General]
DebugThreadUsedMemory=1
Sendo 0=desabilita (padrão) e 1=habilita.
Ao habilitar essa chave, uma coluna será inserida no TOTVS | Monitor para informar a quantidade de memória utilizada para cada processo apresentado no monitoramento.
Se o ambiente estiver utilizando balanceamento de carga, é recomendável que esta parametrização, caso habilitada, seja realizada em todos os serviços do TOTVS | Application Server envolvidos no balanceamento, inclusive o serviço Master/Balance.
Após habilitar/desabilitar essa chave, na seção [General], o TOTVS | Application Server deve ser parado e iniciado novamente, pois essa configuração somente é considerada no momento que o TOTVS | Application Server é iniciado.

Como fazer o acompanhamento
1) Limpar todos os arquivos de log antes de ativar os traces.
2) Quando houver uma nova ocorrência, selecionar os logs citados neste documento de acordo com o ambiente e o cenário do cliente e passar as informações como nome do usuário logado e hora da ocorrência para identificação nos logs.
3) É importante ressaltar que os logs devem ser acionados dependendo do tipo de ocorrência no cliente. Exemplo: caso já tenha sido analisado que a não-conformidade não está relacionada com o ECF de nenhuma forma, não há a necessidade de habilitar os logs vinculados a impressora fiscal.



Fonte: https://tdn.totvs.com/pages/releaseview.action?pageId=235330062

terça-feira, 1 de setembro de 2020

Chave do Windows

No cmd ou powershell digitar o comando abaixo.

 wmic path softwareLicensingService get OA3xOriginalProductKey

domingo, 3 de maio de 2020

Conexão ao DBAccess via Connection String

O Protheus passa a contar com uma conexão mais ágil ao Banco de Dados, com uma configuração descomplicada. Se antes era necessário configurar a conexão no arquivo appserver.ini, alias no DBAccess e ODBC no Sistema Operacional, agora basta uma configuração inicial através de uma tela de wizard, e todas as informações necessárias serão automaticamente guardadas apenas no arquivo appserver.ini.

Importante:

* O arquivo appserver.ini não pode ter a seção [DBAccess] nem as linhas DBAlias, DBServer, DBDatabase e DBPort na seção do [Ambiente].


* A melhoria está disponível apenas para os bancos de dados Oracle, MSSQL e Postgres, nas versões homologadas e dentro do seu ciclo de vida.

Para que essa configuração seja feita, siga os passos abaixo:


1. Remova as linhas de configuração do DBAccess do arquivo appserver.ini, conforme aviso acima;
2. Acesse o Protheus entrando em qualquer módulo;
3. Será exibida uma tela de Comunicação com o Banco de Dados




• DNS do servidor do DBAccess: Endereço IP do servidor onde está o Dbaccess

• Porta do servidor do DBAccess: Porta que o DBAccess está iniciando

• Banco de dados proprietário: Banco de dados que está sendo utilizado

• Driver: Driver a ser utilizado para o banco de dados (Oracle não possui driver, deixar em branco)

• Schema ou banco de dados: Nome da base de dados

• DNS do servidor de banco de dados: Endereço IP do servidor onde está o banco de dados

- Para Oracle, é o endereço do servidor+porta+Service Name, encontrado no tnsname.ora:

P11A=


(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = VMFW66213.sp01.local)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = orcl)
No exemplo acima, o DNS será : VMFW66213.sp01.local:1521/orcl
- Para MSSQLServer basta incluir o nome/endereço do servidor+porta
Ex.: SPON010114158\SQLEXPRESS:1433
- Para Postgres basta informar o endereço com porta.
Ex.: localhost:5433


• Login do banco de dados: Usuário do banco de dados (dbo) que irá acessar o sistema. Importante: O usuário deve ter as permissões mínimas necessárias para acesso ao sistema e criação de usuários

• Senha do banco de dados: Senha do usuário acima

4. Após configurar, clique em Validar conexão para testar se a configuração está correta. Caso positivo, será exibida uma janela Conexão realizada com sucesso.





5. Clique em Gravar para confirmar a configuração
6. A partir deste momento o sistema já está configurado e pronto para uso. Os dados da conexão foram gravados no arquivo appserver.ini, e esta tela de configuração não será mais apresentada.
A tela de wizard de conexão será exibida para cada ambiente que for acessado e que não tiver as linhas de configuração DB no arquivo appserver.ini.

Aviso:


O usuário dbo e a sua senha são gravadas no banco de dados, em uma tabela específica. Os dados são gravados criptografados e seu acesso somente é permitido por um usuário específico criado pelo Protheus (sysdba). Somente ele é capaz de ler a tabela e descriptografar os dados guardados. De posse do usuário e senha do banco, ele realiza as conexões do ERP.





From <https://tdn.totvs.com/pages/releaseview.action?pageId=359466064>

segunda-feira, 3 de fevereiro de 2020

Lentidão no Protheus 12

1. Atualização:1.1. Verifique se a versão de LIB, Appserver, Smartclient, DBAccess e License Server é igual a última disponível no Portal do Cliente porque estão sendo implementadas constantemente algumas melhorias que visam otimizar a  performance para o ambiente do Protheus 12. Algumas das melhorias são:
  • Carga do RPO
  • Abertura de Thread
  • Busca de usuário
1.2. As atualizações do DBAccess e Appserver devem ser realizadas simultaneamente na maioria dos casos, pois as alterações realizadas na biblioteca dbapi do Appserver são refletidas no DBAccess.

2. Configuração:
2.1. Filtro:
Quando a lentidão é gerada ao tentar filtrar por um campo, por exemplo na rotina Contas a Pagar, ao tentar filtrar um valor que corresponde a um título pago que não possui índice, neste caso a lentidão é gerada devido à ausência de índice. Para solucionar basta criar um índice para o campo que deseja realizar o filtro.

2.2. Customizações;Para verificar se a lentidão é causada por rotina customizada através de ponto de entrada no sistema, inclua no INI do server dentro do ambiente utilizado a linha IXBLOG=NORUN. Caso não ocorra a lentidão é necessário que sejam reanalisadas as customizações.

Ex.
[Environment]

IXBLOG=NORUN

2.3. Smartclient:É recomendado que seja executado o Smartclient de forma local porque assim o tráfego de rede é minimizado.

2.4. Latência:A latência de rede é um dos pontos que pode causar lentidão no Protheus porque todos os dados trafegados entre o Smartclient e Server serão afetados. Para verificar se a latência de rede está impactando na performance do Protheus, execute o programa U_NETTEST no período de 1 hora e analise os resultados que estão acima de 100ms. Acima de 100 ms de resposta a lentidão já é notada pelo usuário.

2.5. Política de Appserver:Manter a coesão dos Appservers é uma das boas práticas que garante a boa performance do Protheus, neste caso sugerimos a distribuição por responsabilidades entre os Appservers.

Arquitetura sugerida
– Appserver (Master)
– Appserver (Slaves)
– Appserver (Jobs – Schedule)
– Appserver (Web Service – Portal)

2.6. Consumo de memória:Caso identifique que o consumo de memória dos serviço do Protheus esteja elevado, sugerimos a análise de dois pontos:
1. Quantidade de usuário conectados no Slave.
Para este caso deverão ser criados novos Slaves de acordo com o recurso computacional disponível porque assim o volume de conexão entres os Slaves será balanceado e consequentemente o consumo de memória será diminuído neles.
2. Consumo por Programa.
Quando for alto consumo por programa, deverá identificar e isolar o programa com alto consumo de memória, em seguida gerar os logs e encaminhar para equipe específica analisar.

DebugThreadUsedMemory: http://tdn.totvs.com/display/tec/DebugThreadUsedMemoryServerMemoryInfo: http://tdn.totvs.com/display/tec/ServerMemoryInfoConsoleMaxSize: http://tdn.totvs.com/display/tec/ConsoleMaxSize+–+29343

2.7. Numeração Automática:Para uma melhor performance do ambiente é recomendado o uso do controle de numeração pelo License Server.
Verifique se no appserver.ini do License Server está configurado o parâmetro EnableNumber=1, que realiza o controle de numeração automática diretamente pelo License Server Virtual. Porque quando o controle é realizado através das tabelas SXE/SXF é aumentada a concorrência no gerenciamento do Ctree e causa impacto de performance significativo no Protheus.
Abra o arquivo appserver.ini do License Server, localize a seção LICENSESERVER para inserir o parametro EnableNumber
[LICENSESERVER]
Enable=1
Port=5555
ShowStatus=0
EnableNumber=1
LicenseFile=lsinitialize.inf
IPCGOTIMEOUT=45000
IPCRETURNTIMEOUT=90000
NUMBERVAL=1

2.8. ShowStatus:Verifique se no appserver.ini do License Server está configurado o parâmetro ShowStatus igual a 0 (desabilitado), com o objetivo de não exibir todas as informações de licenças de usuário. Quando o parâmetro ShowStatus está com o valor igual a 1 (ativado) é gravado um grande volume de informações no console.log e gera impacto no desempenho do sistema.

2.9. TraceIndex:Verifique se no dbaccess.ini o parâmetro TraceIndex está com o valor de 0 (desabilitado), este parâmetro deverá ser habilitado somente quando estiver realizando o monitoramento da ferramenta. ( TraceIndex=0 )

2.10. Monitor de Índices:
Verifique se o Monitor de Índices do DBAccess está desligado porque quando este recurso está ligado impacta diretamente na performance do Protheus 12. É um recurso em especial para as bases legadas.

2.11. Arquivos da System:Verifique se a quantidade de arquivos no diretório SYSTEM localizado na PROTHEUS_DATA é inferior à 10.000 (dez mil). Porque a partir do momento em que o diretório SYSTEM armazena mais de 10.000 (dez mil) arquivos, o Protheus começa a perder desempenho durante a sua utilização. Os arquivos que podem ser deletados da pasta SYSTEM são: *.tmp, sc*.log, sc*.dtc, sc*.cdx e arquivos sc* sem extensão.

2.12.  Auditoria de Tabelas:Quanto menor a abrangência de entidades que se deseja auditar (tabelas e campos) e quanto menos operações desejadas (incluir, alterar ou excluir), menor será o impacto sobre o desempenho do sistema após a aplicação do Embedded Audit Trail. Uma análise cuidadosa do que é necessário auditar resultará em um desempenho melhor do produto.

A Totvs não recomenda a auditoria de todos os campos para operação de inclusão em tabelas de movimentos, principalmente das tabelas que possuem grande quantidade de campos. Como a operação de inclusão registra todos os campos sujeitos à auditoria, o impacto na performance pode ser significativo.

2.13. Opções de Energia:Verifique se a configuração de energia do servidor está selecionada a opção Alto Desempenho (High Performance). Identificamos que com a configuração de energia Equilibrado é apresentado um tempo maior para abertura de Thread e leitura em disco.

2.14. Indexação Automática do FileSystem:Verifique se o recurso de Indexação Automática de disco está desabilitado na partição do disco onde a aplicação foi instalada. Quando este recurso está habilitado o mesmo acaba degradando a performance do Protheus.

2.15. Escaneamento do Antivírus na pasta Protheus_Data (Totvs):Verifique se está desabilitado o Scan em tempo real do antivírus no diretório PROTHEUS_DATA da aplicação do ambiente de Produção ou para os arquivos listados abaixo, pois quando habilitado o Scan em tempo real há impacto direto na performance do Protheus quando está sendo realizada a leitura dos arquivos. Caso esta configuração não seja permitida pela política de segurança da empresa, deverão ser excluídas da varredura on-scan do antivírus as seguintes extensões:

Na Pasta \Protheus_Data (RootPath)
*.amt
*.cdx
*.idx
*.ind
*.lcx
*.lck
*.int
*.dtc
*.log
*.tmp
*.mem
*.sem
*.fcs

Na pasta \apo (SourcePath)
*.rpo

2.16.  Hardware do Servidor de Aplicação:Verifique se o hardware disponível para o servidor de aplicação atende à demanda de conexões e das rotinas que exigem maior hardware no horário de pico em que o sistema está sendo utilizado por quase todos os usuários. Para auxiliar com esta análise pode contatar a equipe TIS através do e-mail tis.comercial@totvs.com.br e solicitar que seja realizado um Projeto de dimensionamento de Ambiente (Sizing).

3. Manutenção3.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 a Totvs recomenda seu uso, através dos scripts abaixo.

Método gather_schema_statsO 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.

A Totvs recomenda o uso do script abaixo.
A Totvs recomenda 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’);



fonte
https://www.blogadvpl.com/sugestao-lentidao-no-protheus-12/