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/

quinta-feira, 4 de julho de 2019

MP - SIGALOJA - A DLL: MP2032.DLL e/ou SIUSBXP.DLL não foi encontrad0

Atualizado em:

4 de julho de 2018 18:34

Ocorrência
No Microsiga Protheus, ao tentar acessar o sistema é apresentada a mensagem:

A DLL: MP2032.DLL e/ou SIUSBXP.DLL não foi encontrado.

Ambiente
Microsiga Protheus - SIGALOJA -SIGAFRT - TOTVS PDV - Aplicável a partir da versão 11.80

Causa
Esse incidente ocorre, pois não existe as Dlls.

Solução
Para solucionar essa ocorrência, realize os seguintes passos:
1. Faça backup da pasta Smartclient;
2. Baixe o anexo contido nesse artigo(mp2032.zip);
3. Realize aplicação dentro da pasta Smartclient do PDV.

quarta-feira, 19 de junho de 2019

acesso exclusivo ao SM0

Produto	TOTVS Automação Fiscal
Versão	12
Ocorrência	Na tentativa de criação de um novo Grupo de Empresas através da opção de menu: Atualizações → Empresa → Cadastro → Grupo de Empresa, ocorre a mensagem: NecessárioC.
Solução	Ocorre quanto existe algum serviço da aplicação consumindo o cadastro de empresas (SM0), e neste caso será necessário reiniciar (ou parar) o serviço que está acessando este cadastro. Dica: Para saber qual o serviço que está consumindo este cadastro, acesse o diretório $\system\ - onde $ se trata do diretório de instalação do sistema - e tente renomear o arquivo sigamat.emp. O sistema operacional impedirá esta ação e informará qual o serviço que impede que o arquivo seja renomeado.

segunda-feira, 20 de maio de 2019

Migração do Dicionário de Dados para o Banco de Dados

Apresentamos a melhoria de utilização do Dicionário de Dados no Banco de Dados, que visa proporcionar maior agilidade na leitura do dicionário, centralização dos dados no SGBD, otimização nas buscas de informações, entre outras. Para que seu dicionário de dados seja migrado para o banco de dados, a partir do uso da LIB e Binário indicados no quadro ao lado, seguem abaixo as características, requisitos e procedimentos.

1. Descrição

A migração consiste na mudança de alguns arquivos locais de infraestrutura armazenados atualmente no diretório System para um SGBD em ambientes que utilizem banco de dados relacional.

O processo envolve os seguintes arquivos:

Usuários
- SIGAPSS.spf
Menus
- Todos os arquivos .XNU
Empresas
- SIGAMAT.emp
- XX8
- XX9
Help
- SIGAHLP
Perfis de usuários
- Profile
Metadados
- SXs
- Demais dicionários utilizados pela LIB para Event Viewer, Schedule, Mile e EAI.

2. Vantagens

A migração oferece as seguintes vantagens:

Para o Cliente
- Melhorar a gestão de configuração do Cliente;
- Centralização dos metadados e dos dados sobre os cuidados do SGBD;
- Uso do C-Tree Server não obrigatório.

Para o Usuário
- Abertura do Sistema mais rápida.

Para o sistema Microsiga Protheus
- Diminuição do I/Os no AppServer;
- Otimização dos programas na busca de informação;
- Maior facilidade para integração com o Identity.

3. Pré requisitos

Para executar o processo de migração, os seguintes itens devem ser atendidos (eles serão validados antes do processo e a migração não é executada caso algum deles não seja atendido):
• Validação de todas as customizações através da ferramenta TOTVS CodeAnalysis (todos os bugs apontados devem estar corrigidos antes de iniciar a migração);
• LIB, Binário e DBAccess em versões conforme quadro lateral desta página;
• PDV ou Retaguarda de PDV, por hora, não são suportados;
• O Protheus já deve estar na Release 23 antes de iniciar a migração do Dicionário para o Banco. Não é permitido migrar para a Release 23 e o Dicionário para o Banco ao mesmo tempo;
• Utilização do License Server Virtual (inclusive para controle de numeração automática) com versão igual ou superior a 01.03.013 (download aqui);
• Cadastro de usuários não pode possuir dois ou mais usuários com o mesmo login;
• E-mail de validação para recuperação da senha do Administrador;
• Chave TOPMEMOMEGA configurada no arquivo appserver.ini do Servidor de Aplicação;
• Obrigatoriedade do menu do Configurador (SIGACFG.XNU) estar dentro do StartPath (pasta System na configuração padrão). Caso o arquivo não esteja disponível para a importação, será exibida a mensagem Menu do configurador não disponível no Startpath para importação e o processo será bloqueado.

Recomendamos que seja feita uma avaliação de sizing de ambiente (servidores e banco de dados) antes de efetuar a migração. A equipe TIS (TOTVS Infra Services) pode efetuar esta avaliação.

4. Observações importantes sobre o processo

• Registros deletados não serão migrados;
• Após migrar, não é possível reverter o processo de maneira automática;

Mudanças
Quando o Microsiga Protheus é executado utilizando os arquivos de Infraestrutura no SGBD algumas mudanças ocorrem no sistema:
• Para cada conexão de usuário, serão criadas 2 conexões com o DBAccess, sendo que uma delas não consome licença e é não transacionada;
• A conexão utilizada pelas tabelas de infraestrutura não é transacionada;
• É proibido abrir o arquivo de Empresa(SIGAMAT) com DBUseArea, deve-se utilizar OpenSm0 ou OpenSm0Excl;
• É proibido abrir os arquivos de dicionário com DBUseArea, deve-se utilizar a função OpenSX.
• Com o dicionário no Banco de Dados, o Repositório de Imagens sempre será enviado ao banco, desconsiderando o valor do parâmetro MV_REPOSIT

5. Procedimento para implementação

Antes de executar o compatibilizador MPSYSTODB é imprescindível:

- Realizar o backup do banco de dados do produto em que será executado o compatibilizador;
- Realizar o backup da pasta de dados e dicionários \TOTVS 12\Microsiga\Protheus_Data (a indicação desta pasta refere-se à instalação padrão do Protheus 12. Se na sua instalação foram utilizadas pastas diferentes, deve-se adequar este caminho ao seu cenário);
- Essa rotina deve ser executada em modo exclusivo, ou seja, nenhum usuário deve estar utilizando o sistema.

01. Utilizando a ferramenta TOTVS CodeAnalysis, faça a verificação e correção de todas as customizações do seu ambiente. Após a correção de todos os bugs (imagem abaixo), tire uma printscreen da tela final.

02. Abra um ticket pelo Portal do Cliente para a equipe de Suporte do Framework Protheus. Neste ticket, anexe a printscreen da tela do CodeAnalysis, e envie também o TOTVS ID do License Server Virtual que será utilizado neste ambiente.

03. Aguarde o contato do Suporte Framework, informando o Token de Migração.

04. Em posse do Token, abra o SmartClient, e no Programa Inicial digite MPSYSTODB

05. Clique em OK para continuar.

06. Após a confirmação será exibida uma tela com informações sobre o procedimento que será executado. Leia e clique em Avançar.

07. Ao avançar será solicitado Usuário, Senha e Token para migração. O usuário e Senha obrigatoriamente deve ser do Administrador. Insira o Token fornecido pelo Suporte Framework e clique em Avançar.

08. Será executada uma verificação para analisar se todos os pré-requisitos da migração são atendidos, caso algum deles não seja, deve-se encerrar o processo, corrigir o problema e executar o compatibilizador novamente. Nesse momento também são listados os menus padrões que não foram encontrados no diretório System do ambiente e que portanto não serão migrados, caso algum desses menus deva ser migrado, encerre o processo, coloque o arquivo no diretório System e inicie o compatibilizador novamente. Se todos os itens estiverem validos, clique em Avançar.

09. Agora é necessário validar o e-mail do Administrador. Essa etapa é importante pois depois da migração, caso o usuário Administrador esqueça a senha, somente será possível recuperar a mesma utilizando esse e-mail. Preencha o e-mail (caso o usuário Administrador já tenha um e-mail cadastrado, será apresentado o mesmo, sendo possível trocar esse endereço caso seja necessário), o SMTP, o login e a senha que serão usados pelo servidor para enviar o e-mail. Depois disso clique em Avançar.

10. Será enviado um e-mail com um código para o endereço informado anteriormente. Aguarde o recebimento e preencha a caixa Chave de Segurança com o código recebido. Clique em Avançar.

11. É mostrada uma lista com todos os itens que serão migrados para o SGBD. Clique em Iniciar.

12. Aguarde o fim da migração, isso pode demorar algumas horas. Clique em Finalizar.

Caso ocorra algum erro durante o processo de migração e o mesmo aborte o procedimento, deve-se executar o compatibilizador novamente para restaurar os arquivos como estavam antes e caso deseje, executar a migração novamente.

6. Utilização

Após realizar o processo de migração, deve-se utilizar o sistema normalmente e a partir desse momento o sistema irá utilizar as tabelas transferidas para o SGBD ao invés de usar os arquivos locais.