- Este tópico contém 11 respostas, 4 vozes e foi atualizado pela última vez 10 anos, 2 meses atrás por
rman.
-
AutorPosts
-
4 de junho de 2014 às 7:42 pm #106667
mpvargas
ParticipanteCaros 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.
Obrigado4 de junho de 2014 às 10:14 pm #106668rman
Participante@mpvargas
Verifique na VIEW DBA_AUDIT_SESSION.
Se o objetivo é que o usuário não acesse mantenha o LOCK no usuário. :whistle:
5 de junho de 2014 às 12:54 am #106671Wender
ParticipanteOlá 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
5 de junho de 2014 às 3:40 pm #106672rman
Participante@Wender
Só uma pergunta, quem faz o COMMIT desta transação?
5 de junho de 2014 às 5:52 pm #106678mpvargas
ParticipanteObrigado pela ajuda
Com relação a trigger, será que eu posso colocar um commit no final?5 de junho de 2014 às 6:31 pm #106680Wender
ParticipanteOlá 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.
5 de junho de 2014 às 6:34 pm #106681mpvargas
Participante@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?5 de junho de 2014 às 6:58 pm #106682Wender
Participante@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.
5 de junho de 2014 às 7:58 pm #106683mpvargas
ParticipanteObrigado @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.5 de junho de 2014 às 8:45 pm #106684Wender
ParticipanteOlá 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.
16 de junho de 2014 às 6:07 pm #106705versant
ParticipanteNão precisa de COMMIT mesmo?
É uma trigger “after logon on database” e não “after INSERT/UPDATE/DELETE”.16 de junho de 2014 às 6:15 pm #106706rman
Participante@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:
-
AutorPosts
- Você deve fazer login para responder a este tópico.