ProtheusProtheus® |
Ocorrência: | Mensagem: Tentativa de reservar registro no Alias |
x X em EOF Stack de chamadas em MSRLOCK.eof Controle de transaçoes Habilitado Tenta novamente ? Essa mensagem sera fechada em 5 segundos |
Ambiente: | SIGAFAT - Faturamento |
Passo a passo: |
Esta é uma ocorrência que não é reproduzida, indevidamente, em ambiente padrão atualizado. Está geralmente sujeita ao cenário do cliente. Asim, é preciso rastrear possíveis causas.
A mensagem referente a EOF Stack em MSRLOCK indica que o registro em questão está reservado por outro processo.
Esta inconsistência pode acontecer em duas principais situações:
1º o uso do registro por outro usuário e 2º uma customização / processo que iniciou indevidamente o tratamento e unlock do registro.
Segue sequência de verificações / procedimentos a realizar:
1º - reiniciar o servidor (parando os serviços do TOP, Banco de dados e Server) e realizar novos testes.
Se erro persistir, seguir o segundo procedimento:
2º - verificar se o arquivo msrlock.eof gravado na pasta system existe alguma customização no sistema que envolva o alias apresentado na mensagem. Realizar este procedimento de teste
A) Anexar o arquivo criado pelo comando IXBLOG:
No arquivo *.INI do Server, no ambiente que fará o teste, adicionar a linha: IXBLOG=LOGRUN ao final das configurações do ambiente e salvar.
Ao entrar no sistema será apresentada a mensagem "USER FUNCTION debug is active, you will have performance cost", isso significa que o sistema está rodando o IXBLOG. Caso a mensagem não seja apresentada revise o processo no *.INI, e posteriormente baixe e suba o Server.
Simular o processo até que gere a inconsistência citada.
Na pasta Protheus_Data será criada a pasta IXBLOG e, dentro desta, um arquivo *.LOG com seu nome de usuário e registro de Pontos de entrada/Customizações identificadas no processo, para análise.
B) Testar retirando influencia de Customizações e Pontos de Entrada:
Alterar a linha de comando IXBLOG=LOGRUN para IXBLOG=NORUN Image Added
|
| Conceito: | O controle de transação é uma ferramenta importante que garante a integridade de dados quando uma determinada operação é realizada no Banco de Dados.O Protheus possui o parâmetro MV_TTS que quando ativado garante que este processo exista nos processos críticos de transação de arquivos
As alternativas existentes quando da atualização de tabelas são: - Efetivar a transação - quando realizada com sucesso
- Voltar a status anterior (rollback) - desfaz toda a transação iniciada quando o final da transação não foi concluído com sucesso. Isto garante a total integridade dos dados.
A mensagem "EOF Stack em MSRLOCK" indica que a rotina tentou reservar um registro para ser manipulado no processamento; mas o ponteiro da tabela estava em FIM DE ARQUIVO (MODO EOF) pois não localizou o dado procurado na Tabela.
Ou seja, algum dado (relacionado a este registro que está sendo processado) está inválido / não foi localizado, apresentando quebra de integridade. É gravado um arquivo de log denominado msrlock.eof na pasta system. Para uma correta conferência, deve-se realizar o processo com a ocorrência em ambiente de homologação onde ocorra o problema |
ou em ambiente exclusivo (logo em seguida de ter reiniciado o servidor - antes da primeira reprodução do erro):, após apagar este registro (para eliminar dados gravados anteriormente).
| Dica |
|---|
| Suponhamos que a mensagem ocorre ao tentar gerar / excluir um Doc. de Saída.
Então algum dado relacionado com esse Doc de Saída está inválido / não foi localizado, apresentando quebra de integridade.
Pode por exemplo ser algo inválido no cadastro do TES utilizado no Pedido de Vendas; pode ser o código do Cliente / Fornecedor / Loja estar registrado um código inválido, que não existe; pode conter um código de Produto no grid, ou um código de condição de Pgto, ou o código do Item, ou outro dado qualquer o qual não existe/ não é válido etc.
|
Exemplo: |
Procedimentos: | | Aviso |
|---|
| Caso o ambiente esteja armazenado no Cloud Data Center da TOTVS, será necessário acionar pontualmente o Suporte Cloud mencionando os itens específicos que necessitam de intervenção do Cloud, para que forneçam os dados mencionados para análise. |
| Deck of Cards |
|---|
| startHidden | false |
|---|
| effectDuration | 0.5 |
|---|
| id | Custo Médio |
|---|
| effectType | horizontal |
|---|
| loopCards | true |
|---|
| | Card |
|---|
| default | true |
|---|
| id | Etapa 1 |
|---|
| label | Etapa 1 - Rastreamento do dado incorreto relacionado ao registro |
|---|
| É necessário rastrear especificamente no ambiente para identificar qual registro da base está com o problema.
Deste modo, a primeira análise é avaliar se os registros que está tentando processar possuem dados válidos no Banco, principalmente para a Tabela apontada no alerta e as relacionadas ao processo executado.
Recomenda-se realizar simulações para isolar o problema / o registro.
Exemplo, inserir um registro idêntico na base de dados e verificar se o registro é gravado nas tabelas com os mesmos dados e se o problema também ocorre.
Este tipo de informação incorreta pode ter sido incluído ou por manipulação de dados no Banco (procedimento este não indicado) ou pela própria rotina sem ter ocorrido a validação adequada (possivelmente devido à uma das causas mencionadas abaixo).
|
| Card |
|---|
| default | true |
|---|
| id | Etapa 1 |
|---|
| label | Etapa 2 - Ver Customizações/Personalizações em seu ambiente |
|---|
| - Personalização por Ponto de Entrada:
Algumas personalizações utilizam os comandos dbSeek, MsSeek, dbGoTo e etc. que desposicionam os registros de tabelas utilizadas nas rotina do produto padrão causando o problema de "EOF Stack em MSRLock". Para este caso recomendamos que utilize um RPO limpo sem customizações para verificar se o problema esta sendo causado por alguma personalização.
Caso não seja possível utilizar um repositório limpo para o teste, é necessário habilitar em seu ambiente a chave IXBLOG=NORUN (Para informações acesse: http://www.tdn.totvs.com.br/display/public/mp/Chave+IXBLOG)
Registrar a linha de comando IXBLOG=NORUN no ini do server dentro da sessão do ambiente
|
|
|
Simular o processo e verificar se a inconsistência permanece
|
|
|
.- !
Após a execução do procedimento a linha criada no *.INI do server deve ser removida, pois pode causar baixa performance no sistema se mantida.
|
|
|
Se erro persistir mesmo no teste "B", seguir o terceiro procedimento:
3º - dropar o alias e os arquivos *.cdx (realizando backup, deixando a tabela ser recriada e appendando os registros do bakcup) e realizar novos testes.
Se erro persistir, seguir o próximo procedimento:
4º - certificar-se de estar com últimas atualizações do Portal do Cliente. Caso não, em ambiente de homologação, aplicar último RPO e verificar se corrige o problema.
Se erro persistir, seguir o próximo procedimento:
5º -
Importante:
OBS: Caso ainda assim permaneça, é gravado um arquivo de log denominado msrlock.eof na pasta system.
Para a correta conferência, deve-se realizar o processo com a ocorrência em ambiente de homologação onde ocorra o problema, após apagar o arquivo já gravado no diretório (para eliminar dados gravados anteriormente).
- Personalização por Dicionário de Dados:
Verificar se há customizações na Estrutura do Protheus, como por exemplo, Índices (SIX) ou gatilhos (SX7).
Realizar backup dos arquivos na Pasta System e recriar com um dicionário de dados padrão a atualizado. Refazer o processo.
|
| Card |
|---|
| default | true |
|---|
| id | Etapa 1 |
|---|
| label | Etapa 3 - Inconsistência na rotina possivelmente causada por atualizações incompatíveis no ambiente |
|---|
| - Certificar-se de estar com últimas atualizações do Portal do Cliente.
|
|
|
- Em ambiente homologação testar com último RPO, Binarios, DBACCESS, LIB e pacote quinzenal de atualizações. Verificar se neste cenário ocorre o problema.
|
|
| Aviso |
|---|
| Há procedimentos incisivos ao sistema em alguns dos processos mencionados, que devem ser realizados por sua Equipe de TI e, aconselhamos que caso tenha alguma dúvida no processo, solicite acompanhamento de um consultor TOTVS.
|
|
Os procedimentos indicados são utilizados para rastrear a possível causa da |
|
reserva do Aliasocorrência.
Caso ainda ocorra |
|
reserva indevida, apesar da devida realização dos procedimentos, |
|
será será necessário solicitar auxilio |
|
de Consultoria Totvs da equipe de Suporte Investigativo TOTVS para que acesse remotamente a sua base, visando avaliação/ debug da rotina para investigá-la e identificar a origem do problema. |
|
Observações: | Há procedimentos incisivos ao sistema em alguns dos processos mencionados, que devem ser realizados por sua Equipe de TI e, aconselhamos que caso tenha alguma dúvida no processo, solicite acompanhamento de um consultor Totvs!
