Índice c-tree - Mensagens RebuidIndex

O que significa a mensagem RebuildIndexes?

Dadas as características especiais de uma tabela c-tree, quanto ao controle de criação e localização física, e arquitetura de índices, o TOTVS | Application Server está preparado para lidar com a tabela e seus índices permanentes, aliada a uma rotina interna de tratamento automático de erros de abertura da tabela, o que inclui também uma funcionalidade de rebuild do arquivo de dados e índices associados a tabela.

Para mais informações sobre as características especiais dos índices da tabela c-tree, consulte a documentação Índices c-tree - Características especiais.

Quando, ao abrir uma tabela c-tree, existe a necessidade de recriar o índice interno, permanente ou foi determinado o corrompimento da tabela (por exemplo, em virtude de um término anormal do sistema, como uma queda de energia, processo do c-tree Server^® caiu ou foi derrubado), o TOTVS | Application Server exibe a mensagem a seguir, no momento da abertura da tabela com o nome da tabela e o path completo de acesso em <file>:

--------- RebuildIndexes- <File> -------------- RebuildIndexes: Rebuild succeeded. File:

Ocorrências repetidas da mensagem RebuildIndexes

É muito importante ter cuidado na configuração dos servidores, quando mais de um servidor de aplicação realizar o acesso aos mesmos dicionários e/ou tabelas c-tree. Pois, como o arquivo c-tree possui registrada a informação de sua localização física, se o arquivo for acessado,  por exemplo a partir de um compartilhamento de rede ou um mapeamento de unidade, uma vez detectada pela rotina de abertura que o path utilizado para o acesso é diferente do utilizado para criar a tabela, a rotina de abertura assume que a tabela foi copiada do diretório e/ou renomeada, de modo que os índices permanentes da tabela são apagados da header da mesma e um rebuild do índice interno é novamente realizado.

Isto causa transtornos de acesso à tabela, pois caso a tabela esteja atualmente em uso por outro servidor, não é possível realizar a rebuild da mesma. Para esta situação, temos a configuração da chave CtreeRootPath. Para mais informações da configuração CtreeRootPath, consulte a documentação Configuração do arquivo appserver.ini.

Além disso, quando se tratar de um ambiente em Linux, onde dois servidores de aplicação distintos fazem acesso às tabelas do sistema, são imprescindíveis dois fatores:

1. Ambos os servidores devem possuir uma configuração da seção [LockServer] para controlar os acessos exclusivos às tabelas e demais arquivos da aplicação. Caso ambos os servidores estejam configurados para acesso através de um TOTVS | Application Server, configurado em modo Load Balance, esta configuração da seção [LockServer] é automática, ficando o servidor de balanceamento responsável por este controle. Caso contrário, não havendo um balance, um dos servidores (TOTVS | Application Server) deve ser configurado manualmente como LockServer, e todos os demais servidores que fizerem acesso ao mesmo ambiente físico devem também conter a configuração da seção [LockServer] apontando para o TOTVS | Application Server configurado para tal tarefa.
    
2. O path de trabalho do ambiente (RootPath) deve ser compartilhado entre os demais servidores de aplicação, de modo que todos os servidores de aplicação possuam exatamente o mesmo rootpath de ambiente configurados em todos os ambiente. Por exemplo, no servidor A, onde estão os arquivos fisicamente, o rootpath do ambiente é /home/ERP/ap_data/, e no servidor B, este mesmo caminho deve existir, sendo ele um mapeamento da pasta /home/ERP/ap_data/ do servidor A.