I'm trying to get a better handle on what locked out a specific user when multiple Oracle databases are involved using database links.
sqlplus kjohnston@db2 create user testuser identified by "Dummypass1"; grant create session to testuser; exit; sqlplus kjohnston@db1 create public database link testlink using 'DB2'; create user testuser identified by "Differentpass1"; grant create session to testuser; exit; sqlplus testuser@db1
Run the following a few times until testuser@db2 is locked.
SELECT * FROM dual@testlink;
On DB2, I can query on the following:
SELECT users.username, users.lock_date, aud.os_username, aud.userhost, aud.sessionid, aud.os_process FROM dba_users users JOIN dba_audit_trail aud ON aud.username = users.username AND aud.timestamp = users.lock_date WHERE users.account_status in ('LOCKED', 'LOCKED(TIMED)') AND aud.action = 100 AND aud.returncode = 1017; USERNAME LOCK_DATE OS_USERNAME USERHOST SESSIONID OS_PROCESS TESTUSER 09-MAR-17 09.39.14 SYSTEM VM1 10484322 404:5808
In this case, it's obvious that this lock originated from a database link since the OS_USERNAME is SYSTEM and the USERHOST is VM1, which is a database server (so few people have access to it anyways) where database DB1 is running from.
However, i'm unsure where to go from here in my analysis. Sure, I have the SESSIONID and the OS_PROCESS from dba_audit_trail (as shown above), but I've been unable to successfully query the appropriate table on DB1 in order to narrow down what was running and who was running what on DB1.
I've tried querying
v$session (on SID and AUDSID columns) and
v$active_session_history (on SESSION_ID) on both DB1 and DB2 in an attempt to get more information. However, all attempts to query these tables on either database using either SESSIONID or OS_PROCESS values have failed (0 results returned).
Since there are no private database links on DB1 that connects directly to testuser, it looks like this probably originated from a public proxy database link, but i'm unsure how to find what testuser@db1 was actually running at the time that testuser@db2 got locked out.
Also, consider the possibility that testuser doesn't equate to a specific person, but it is an application schema that many different programmers may have access to.
Also, the logged in user that ran the dblink connection may not even be TESTUSER@DB1 since a user with create any procedure privilege could have:
create procedure testuser.testproc v_var varchar2(1); begin SELECT dummy INTO v_var FROM dual@db2; end testproc; exec testuser.testproc;
Any ideas how I can track down what locked out testuser@db2 (the SQL that was running, preferably) given my supplied example?