Menu de navegação

[mpvargasParticipante]

Caros amigos
Alterei a senha de um usuário para que o mesmo não acesse pois não posso excluir esse usuário.
Todos os dias de manhã esse usuário está com LOCK, como se alguém ou alguma aplicação tivesse tentando acessar com a senha antiga e o LOCK acontecesse pela tentativa de acesso com a senha errada.
Minha dúvida é:
Tenho como descobrir de qual IP estão vindo essas tentativas de conexão?
Obs.: Atualmente não uso o AUDIT.
Obrigado

[rmanParticipante]

@mpvargas

Verifique na VIEW DBA_AUDIT_SESSION.

Se o objetivo é que o usuário não acesse mantenha o LOCK no usuário. :whistle:

[WenderParticipante]

Olá mpvargas,
Visto que você não utiliza AUDIT, poderá obter essas informações poderá criar uma trigger, segue abaixo.

create table audit_login (
username varchar(50),
terminal varchar(50),
IP varchar(50));

create or replace trigger tr_audit_login
after logon on database
declare
v_user varchar(50);
begin
select sys_context(‘USERENV’,’SESSION_USER’) into v_user from dual;
if v_user = ‘SEUUSUARIO’ then
insert into audit_login
select sys_context(‘USERENV’,’SESSION_USER’), sys_context(‘USERENV’,’HOST’), sys_context(‘USERENV’,’IP_ADDRESS’) from dual;

end if;
end;
/

Testei o código esta correto, apenas mude na linha if v_user = ‘SEUUSUARIO’ then altere para o usuário que vc quer auditar, depois é so fazer um select na tabela audit_login .

Abraços

[rmanParticipante]

@Wender

Só uma pergunta, quem faz o COMMIT desta transação?

[mpvargasParticipante]

Obrigado pela ajuda
Com relação a trigger, será que eu posso colocar um commit no final?

[WenderParticipante]

Olá rman,
A lógica da trigger é por definição uma extensão da operação DML, as alterações feitas dentro de uma trigger automaticamente serão confirmadas como parte da execução, por esta razão que trigger não aceita declaração de COMMIT ou ROLLBACK implicito em no caso INSERT, caso insira um COMMIT irá obter o erro (ORA-04092: cannot COMMIT in a trigger), com exceção de autonomous triggers.

Neste caso poderá fazer da seguinte maneira:
DECLARE
PRAGMA AUTONOMOUS_TRANSACTION;

E então colocar o commit após o INSERT.

MPVARGAS não tem a necessidade de inserir o commit no final, conforme reportado o mesmo será confirmado como parte do gatilho.

[mpvargasParticipante]

@Wender
Estou compilando a trigger mas está dando Erro: ORA-01031: privilégios insuficientes
Tentei compilar com o usuário SYS
E confirmei os privilégios de CREATE TRIGGER e CREATE ANY TRIGGER
O que pode ser esse problema?

[WenderParticipante]

@mpvargas,
Usuário SYS já possui estas permissões de create trigger, você esta conectado como SYS e criou a tabela audit_login para qual owner? Tente dar permissão para o Usuário na tabela que foi criada.

GRANT SELECT,INSERT,UPDATE,DELETE ON audit_login TO USUÁRIO;

Já me deparei com problemas em triggers onde o create trigger foi feito com usuário SYSTEM porém referenciava tabela de outro owner, então resolvi dando permissão para SYS e SYSTEM para outra tabela.

[mpvargasParticipante]

Obrigado @Wender deu certo…
A falha foi minha, pois na hora de criar a trigger eu não coloquei o código completo…
Uma outra dúvida
Como eu faço pra incluir DATA e HORA
Eu coloquei o SYSDATE e funcionou blz
Mas gostaria de usar o TIMESTAMP ou alguma outra forma de pegar o horario tb
Obrigado.

[WenderParticipante]

Olá mpvargas,
Que bom que funcionou. Você poderá incluir a seguinte sintaxe:

substr(to_char(systimestamp, ‘DD/MM/YY HH24:MI:SS’),1,17)

Para visualizar o retorno que vai ter, faça o seguinte select e verifique se ficou bom:

select substr(to_char(systimestamp, ‘DD/MM/YY HH24:MI:SS’),1,17) from dual;

Ele vai retornar a data e hora:minuto:segundo que ocorreu, basta você alterar a estrutura da tabela adicionando uma coluna data e incluir esse trecho no na trigger.

Se tiver dúvida de como tem que fazer, favor postar que lhe envio o SQL.

[versantParticipante]

Não precisa de COMMIT mesmo?
É uma trigger “after logon on database” e não “after INSERT/UPDATE/DELETE”.

[rmanParticipante]

@versant

AFTER LOGON ON DATABASE é uma trigger de evento.

Na minha opinião é necessário utilizar um PRAGMA AUTONOMOUS_TRANSACTION e um COMMIT.

A solução sem isso pressupõe que a sessão em algum momento vai executar um COMMIT. Mas desta forma existe um ponto falho, caso for feito apenas um LOGON e LOGOUT essa sessão não será registrada no log de auditoria. :whistle:

[Autor]

Posts