Password limits in account profile * For password_reuse_time and password_lock_time, the value must be at least 1/172800 days or 0.5 seconds but not unlimited for it to take effect. But according to sys.profile$, a value set to anywhere between 1/172800 and 1/86400 causes the limit# column to show 1 (second). Apparently profile$.limit# rounds up the value to a whole second. Also, if it's set to < 8.5 second (i.e. 8.5/86400 days), dba_profiles shows 0 although sys.profile$ does not. * If failed_login_attempts is set and the user can't login with one app but can with another, tell him to try at most failed_login_attempts times in the bad app, and login with the good app once before trying in the bad app again, so the failure counter is reset to zero. This is a way to not mess with failed_login_attempts and yet the user can try many possibilities till he finds his password without locking the account. It works only if he has at least one app that can login. This trick is of course not needed if the good app shows the password in clear text. * Find who tried more than failed_login_attempts times to login with a wrong password: SQL> select os_username, userhost, timestamp, returncode from dba_audit_session where username = 'APP' and action_name = 'LOGON' and timestamp > sysdate - 1 order by 3; OS_USERN USERHOST TIMESTAMP RETURNCODE -------- --------------------- ----------------- ---------- jjohnson PWPLT05/10.111.115.40 20141204 12:46:00 0 <-- success jjohnson PWPLT05/10.111.115.40 20141204 13:43:11 0 jsmith PWPLT05/10.111.115.50 20141205 07:58:58 1017 <-- wrong password jsmith PWPLT05/10.111.115.50 20141205 09:47:40 1017 jsmith PWPLT05/10.111.115.50 20141205 10:18:29 1017 jsmith PWPLT05/10.111.115.50 20141205 10:18:48 1017 jsmith PWPLT05/10.111.115.50 20141205 10:20:24 1017 jsmith PWPLT05/10.111.115.50 20141205 11:19:14 28000 <-- locked * After upgrade from 10g to 11g, password_grace_time, password_life_time and password_lock_time are no longer unlimited by default. (Ref: Note:454635.1) * Users not able to query dba_profiles can query user_password_limits for his own password limits. Profile in general * You can create different profiles for the purpose of grouping users. E.g. alter user jsmith profile accounting; alter user mwilson profile accounting; alter user echan profile legal; Oracle has never provided a table or column to table user$ (or view dba_users) to store comments on users. If it did, that could be used to group users as well. * Limit sessions_per_user is database wide, not instance wide, in RAC. Limiting in an instance scope can be done with a logon trigger (with its overhead).