建全局的触发器，然后看alert日志，里面有相关的错误信息。

CREATE OR REPLACE TRIGGER sys.logon_denied_to_alert

  AFTER servererror ON DATABASE

DECLARE

  message   VARCHAR2(168);

  ip        VARCHAR2(15);

  v_os_user VARCHAR2(80);

  v_module  VARCHAR2(50);

  v_action  VARCHAR2(50);

  v_pid     VARCHAR2(10);

  v_sid     NUMBER;

  v_program VARCHAR2(48);

  v_username VARCHAR2(32);

BEGIN

  IF (ora_is_servererror(1017)) THEN

    -- get ip FOR remote connections :

    IF upper(sys_context('userenv', 'network_protocol')) = 'TCP' THEN

      ip := sys_context('userenv', 'ip_address');

    END IF;

    SELECT sid INTO v_sid FROM sys.v_$mystat WHERE rownum < 2;

    SELECT p.spid, v.program

      INTO v_pid, v_program

      FROM v$process p, v$session v

     WHERE p.addr = v.paddr

       AND v.sid = v_sid;

    v_os_user := sys_context('userenv', 'os_user');

    v_username := sys_context('userenv','authenticated_identity');

    dbms_application_info.read_module(v_module, v_action);

    message := to_char(SYSDATE, 'YYYY-MM-DD HH24:MI:SS') ||' dbuser:' || v_username ||

               ' Password Erro: logon denied from ' || nvl(ip, 'localhost') || ' ' ||

               v_pid || ' User:' || v_os_user || ' with ' || v_program || ' – ' ||

               v_module || ' ' || v_action;

    sys.dbms_system.ksdwrt(2, message);

  END IF;

END;

/

谢谢回复，脚本很好用！

但现在还有个问题，

刚测试了一下从12c的多个pdb的创建dblink（故意使用错误的密码），

再次查询alert日志

发现其中没有与PDB名称相关的信息，

问题：如果生产库有多个PDB,我该如何进一步判断是哪个PDB的哪个dblink导致了目标端用户被锁

这个需要重新改写触发器，加入新的变量v_pdb     VARCHAR2(20); 

使用v_pdb:=SYS_CONTEXT ('USERENV','CON_NAME')  进行赋值，改写message，将该部分拼接进去。

然后再试一下是否有相关数据。

备注：不一定成功，可以试一下。 

logon_denied_to_alert对于非高频系统还是挺不错的，但对于连接频繁的系统，要注意触发器所带来的性能问题。这俩天刚处理了一起因为错误密码频繁连接，产生大量library cache load lock等待(注意是load lock，并非library cache lock，密码延迟验证已设置了28401来避免)，导致实例HANG住无法工作，等待对象是is_servererror。

如果用户被锁不是太频繁的话，logminer也是一种选择，前提是需要开启最小补充日志，通过machine和program，结合listener.log也能定位到源头，缺点是执行挖掘步骤稍复杂些，不如触发器直观，各有利弊。你目前的情况是已经发生了被锁的情况，如果数据库已经开启了最小补充日志，可以先用logminer尝试下。