Ativação do Log de auditoria
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.
Desenvolvimento/Procedimento
1.1. Instalador
O instalador do Log de auditoria é disponibilizado pelo suporte mediante solicitação.
Obs.: Este log somente será habilitado caso o solicitante seja usuário mestre no sistema, possuindo habilidades para alteração de perfil.
Instalando: Na primeira tela é exibido o assistente para instalação (Clicar em Avançar).
Termo de licença, ao marcar a opção de aceitar será habilitado o botão Avançar.
Informar nome do usuário e organização (Clicar em Avançar para continuar a instalação).
Será direcionado o diretório para instalação.
Clicar em Instalar para iniciar a instalação dos arquivos.
Clicar em Concluir para finalizar a instalação.
o diretório de instalação do CorporeRM, pasta Log, é apresentado o plugin RMSPLog.CRM.
Este plugin deverá ser copiado para a pasta do aplicativo que será auditado.
Ao acessar o sistema será possível selecionar as tabelas que controlarão o LOG de auditoria.
(Como ilustrativo utilizamos o RM Portal)
Abaixo é apresentado o plugin já copiado para a pasta do aplicativo que irá controlar o Log de auditoria.
Para que o administrador tenha acesso aos processos do LOG, deve-se habilitar no perfil deste usuário o menu referente à customização.
No menu Customização será disponibilizada a opção “Configuração do log” habilitada.
Selecionar os aplicativos e os campos que serão auditados. Abaixo, segue exemplo do aplicativo RM Portal com os campos habilitados que serão auditados.
Importante: Marcar a opção “LOG ATIVO” para que o processo possa ser iniciado.
pós executar consultas na tabela ZLOG, verifica-se que os dados alterados são gravados nesta tabela para conferências.
Todos os campos auditados inserem dados nesta tabela (ZLOG) ao serem alterados no sistema por algum usuário.
Informações Adicionais:
1) Quanto mais campos e tabelas auditados, mais recursos de hardware (servidor) necessários.
2) Se o LOG for usado com critério, não haverá queda de performance.
3) A perda de desempenho vai depender de dois fatores inversamente proporcionais:
4) Quantidade de processos auditados X Quantidade de Máquina disponível
5) Quando falamos em performance, temos que atentar a algumas regras que devem ser cuidadosamente analisadas.
6) Devemos marcar somente os campos que realmente têm necessidade de auditoria.
Por exemplo, se marcarmos o campo Salário da tabela PFUNC. Este campo não sofre alterações a todo momento, então não há impacto sobre performance.
Ao contrário, se marcarmos um campo de uma tabela que sofre alterações constantes, por exemplo, Valor Original da tabela de Lançamentos, supondo 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 robusto for o servidor, menos impacto 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 momento, informações na tabela de LOG, acarretando 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.
Fonte: Blog oficial da TOTVS
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.
Desenvolvimento/Procedimento
1.1. Instalador
O instalador do Log de auditoria é disponibilizado pelo suporte mediante solicitação.
Obs.: Este log somente será habilitado caso o solicitante seja usuário mestre no sistema, possuindo habilidades para alteração de perfil.
Instalando: Na primeira tela é exibido o assistente para instalação (Clicar em Avançar).
o diretório de instalação do CorporeRM, pasta Log, é apresentado o plugin RMSPLog.CRM.
Este plugin deverá ser copiado para a pasta do aplicativo que será auditado.
Ao acessar o sistema será possível selecionar as tabelas que controlarão o LOG de auditoria.
(Como ilustrativo utilizamos o RM Portal)
Importante: Marcar a opção “LOG ATIVO” para que o processo possa ser iniciado.
Todos os campos auditados inserem dados nesta tabela (ZLOG) ao serem alterados no sistema por algum usuário.
1) Quanto mais campos e tabelas auditados, mais recursos de hardware (servidor) necessários.
2) Se o LOG for usado com critério, não haverá queda de performance.
3) A perda de desempenho vai depender de dois fatores inversamente proporcionais:
4) Quantidade de processos auditados X Quantidade de Máquina disponível
5) Quando falamos em performance, temos que atentar a algumas regras que devem ser cuidadosamente analisadas.
6) Devemos marcar somente os campos que realmente têm necessidade de auditoria.
Por exemplo, se marcarmos o campo Salário da tabela PFUNC. Este campo não sofre alterações a todo momento, então não há impacto sobre performance.
Ao contrário, se marcarmos um campo de uma tabela que sofre alterações constantes, por exemplo, Valor Original da tabela de Lançamentos, supondo 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 robusto for o servidor, menos impacto 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 momento, informações na tabela de LOG, acarretando 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.
Fonte: Blog oficial da TOTVS
Nenhum comentário