Ativação do Log de auditoria – MDI (RM.

EXE)
Ir para o final dos metadados


 Created by Jorge de Assis Pereira Junior, last modified by Maisa Gomes de Oliveira on Mar 10, 2015

Ir para o início dos metadados

Produto : TOTVS Framework Versão: 11.50

Processo : Log de Auditoria

Subprocesso : Ativação do Log de auditoria

Data da : 10/03/2015
publicação

Introdução

O LOG de auditoria é composto por uma série de Triggers que são habilitadas no banco. Podemos selecionar
tabelas e campos para auditoria.
Com ele podemos obter um histórico de todas as inclusões/alterações/exclusões que ocorreram nos campos
selecionados para serem auditados pelo LOG.
Quando selecionamos um campo/tabela para auditoria, automaticamente habilitamos a trigger referente a esta
tabela.
Quando o campo marcado sofre uma ação (inclusão/alteração/exclusão), a trigger é disparada e grava na
tabela de LOG dados sobre o autor da ação e valores alterados.

Parametrizando o LOG

1. No RM.exe acessar o contexto Serviços Globais | Aba Administração | Ícone Log de Auditoria
(Configurações).

Importante: Marcar a opção "LOG ATIVO" para que o processo possa ser iniciado.
 2. Ao selecionar a opção "Log" o sistema apresentará os processos realizados nos campos que foram
auditados.

3. Ao realizar consulta pelo banco de dados na tabela ZLOG será possível visualizar os mesmos dados dos
campos auditados. Lembrando que a tabela ZLOG é responsável por gravar estas informações.
OBS: O mesmo procede para banco de dados ORACLE.
Informações Adicionais:

Quanto mais campos e tabelas forem auditados, mais recursos de hardware (servidor) são necessários.
Se o LOG for usado com critério, não haverá degradação de performance.
A perda de performance vai depender de dois fatores inversamente proporcionais:
O quanto de nossos processos estamos auditando X O quanto de Recursos de Máquina temos disponível
Quando falamos em performance temos que nos atentar a algumas regras que devem ser cuidadosamente
analisadas.
Devemos marcar somente os campos que realmente têm necessidade de auditoria.
Por exemplo, se marcarmos o campo Salário ta tabela PFUNC, este campo não sofre alterações a todo
momento. Não há impacto sobre performance.
Ao contrário, se marcarmos um campo de uma tabela sofre alterações constantes, por exemplo, valor original
da tabela de Lançamentos, suponhamos que o cliente processa em média 200 lançamentos por dia...
isso "pode" ocasionar perda de performance, pois a trigger estará sendo executada a todo momento. É
importante salientar que não há como afirmar que haverá perda de performance, pois vários fatores contribuem
para isso como configuração de máquina e rede. Quanto mais "parrudo" o servidor for, menos impactos
teremos na performance.
Temos relatos de clientes que auditam tabelas que sofrem alterações constantes e nem por isso perderam
performance. Porém, sabemos que seu ambiente é hiperdimensionado.
Um mau exemplo de utilização do Log seria marcar sem critério todos os campos da várias tabelas, isso fará
com que o sistema grave a todo o momento informações na tabela de LOG, acarretaria em uma massa de
dados muito grande dificultando, inclusive, a leitura destes registros.
OBS: O Log é armazenado no banco pelo número de dias parametrizado pelo usuário. Se informado
20 dias, a tabela mantém os registros dos últimos 20 dias. Vale ressaltar que dependendo da quantidade de
campos auditados e dias para armazenamento, a tabela de LOG pode assumir proporções gigantescas que
podem interferir no gerenciamento do SGDB.
O mais importante é ter critério e selecionar para Log somente o que é necessário.

Obs.: Em SGBD's Oracle é necessária a concessão de algumas permissões específicas para utilização
das mesmas.

Quando este permissionamento não é realizado as triggers não são criadas e os registros na ZLOG não
são inseridos. Veja como conceder as permissões para SGBD Oracle no link abaixo:

Solucionando Erro: Log de auditoria não grava os dados auditados na tabela ZLOG (Oracle)